Re: the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h

[Rich Felker <dalias@libc.org>]

On Sat, Nov 01, 2014 at 05:22:30PM +0100, Szabolcs Nagy wrote:
> * ????????? <jianzhong.huang@i-soft.com.cn> [2014-10-31 11:42:35 +0800]:
> > 
> > In firefox, there is a system_wrapper header include sched.h, but in hunspell codes, calloc and free was redefined, so there is a conflicts here.
> > for example, in "extensions/spellcheck/hunspell/src/hunspell_alloc_hooks.h"
> > #define calloc(count, size) HunspellAllocator::CountingCalloc(count, size)
> > 
> 
> a simple fix for that in musl is
> 
> 	void *(calloc)(size_t, size_t);
> 
> or
> 
> 	#define CPU_ALLOC(n) __cpu_alloc(n)
> 	static __inline cpu_set_t *__cpu_alloc(size_t _n)
> 	{
> 		extern void *(calloc)(size_t,size_t);
> 		return (calloc)(1,CPU_ALLOC_SIZE(_n));
> 	}
> 
> which almost gets the namespace right: only a non-function like
> calloc macro defined before sched.h would be an issue

Yes, I like moving the declarations to non-file-scope better.

> getting the namespace completely right would need a new extern
> identifier in musl that aliases or wraps calloc
> 
> but _GNU_SOURCE has no well defined namespace requirement
> so it is hard to justify workarounds that spill over into
> other parts of the libc

I think the problem may be that GCC activates _GNU_SOURCE by default
for C++. Am I right about this? If so, perhaps we should look for
things that could cause excessive breakage under this behavior and try
to fix them. Or (easier) we can just wait until somebody finds a
problem and address them on a per-case basis.

Rich