* the prototype decl of memcpy/memcmp/calloc/free should not in sched.h @ 2014-10-31 3:03 黄建忠 2014-10-31 3:24 ` Rich Felker 0 siblings, 1 reply; 7+ messages in thread From: 黄建忠 @ 2014-10-31 3:03 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 227 bytes --] Hi, there, sched.h in musl should not contains the prototype declarations of "memcpy/memcmp/calloc/free" func. memcpy/memcmp already in string.h calloc/free already in stdlib.h Any reason they should exist in sched.h? [-- Attachment #2: Type: text/html, Size: 319 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: the prototype decl of memcpy/memcmp/calloc/free should not in sched.h 2014-10-31 3:03 the prototype decl of memcpy/memcmp/calloc/free should not in sched.h 黄建忠 @ 2014-10-31 3:24 ` Rich Felker 2014-10-31 3:42 ` the prototype decl of memcpy/memcmp/calloc/free shouldnot " 黄建忠 0 siblings, 1 reply; 7+ messages in thread From: Rich Felker @ 2014-10-31 3:24 UTC (permalink / raw) To: musl On Fri, Oct 31, 2014 at 11:03:35AM +0800, 黄建忠 wrote: > Hi, there, > > sched.h in musl should not contains the prototype declarations of "memcpy/memcmp/calloc/free" func. > > memcpy/memcmp already in string.h > calloc/free already in stdlib.h > > Any reason they should exist in sched.h? They're present only under _GNU_SOURCE mode, and the reason is that musl's CPU_* macros for working with cpu sets for affinity use these functions directly rather than having additional exported symbols in a protected namespace to do the work. Is this approach causing a problem for you? Rich ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h 2014-10-31 3:24 ` Rich Felker @ 2014-10-31 3:42 ` 黄建忠 2014-11-01 16:22 ` Szabolcs Nagy 0 siblings, 1 reply; 7+ messages in thread From: 黄建忠 @ 2014-10-31 3:42 UTC (permalink / raw) To: musl; +Cc: Rich Felker [-- Attachment #1: Type: text/plain, Size: 1485 bytes --] I encounter a problem that use clang/libc++/libc++abi only to build the whole system(As i remeber gcc should be ok). 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) It's not a big issue and can be fixed in firefox. but still feel strange that these declarations exists in sched.h and also a little bit conflict with common sense. Please consider it. ------------------ Original ------------------ From: "Rich Felker"<dalias@libc.org>; Date: Fri, Oct 31, 2014 11:24 AM To: "musl"<musl@lists.openwall.com>; Subject: Re: [musl] the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h On Fri, Oct 31, 2014 at 11:03:35AM +0800, 黄建忠 wrote: > Hi, there, > > sched.h in musl should not contains the prototype declarations of "memcpy/memcmp/calloc/free" func. > > memcpy/memcmp already in string.h > calloc/free already in stdlib.h > > Any reason they should exist in sched.h? They're present only under _GNU_SOURCE mode, and the reason is that musl's CPU_* macros for working with cpu sets for affinity use these functions directly rather than having additional exported symbols in a protected namespace to do the work. Is this approach causing a problem for you? Rich [-- Attachment #2: Type: text/html, Size: 1983 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h 2014-10-31 3:42 ` the prototype decl of memcpy/memcmp/calloc/free shouldnot " 黄建忠 @ 2014-11-01 16:22 ` Szabolcs Nagy 2014-11-01 17:02 ` Rich Felker 0 siblings, 1 reply; 7+ messages in thread From: Szabolcs Nagy @ 2014-11-01 16:22 UTC (permalink / raw) To: musl; +Cc: Rich Felker * ????????? <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 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h 2014-11-01 16:22 ` Szabolcs Nagy @ 2014-11-01 17:02 ` Rich Felker 2014-11-01 20:49 ` Alexander Monakov 2014-11-02 4:48 ` Rich Felker 0 siblings, 2 replies; 7+ messages in thread From: Rich Felker @ 2014-11-01 17:02 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h 2014-11-01 17:02 ` Rich Felker @ 2014-11-01 20:49 ` Alexander Monakov 2014-11-02 4:48 ` Rich Felker 1 sibling, 0 replies; 7+ messages in thread From: Alexander Monakov @ 2014-11-01 20:49 UTC (permalink / raw) To: musl > I think the problem may be that GCC activates _GNU_SOURCE by default > for C++. Am I right about this? Yes, that's true; see for example http://lwn.net/Articles/590504/ and https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined Alexander ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: the prototype decl of memcpy/memcmp/calloc/free shouldnot in sched.h 2014-11-01 17:02 ` Rich Felker 2014-11-01 20:49 ` Alexander Monakov @ 2014-11-02 4:48 ` Rich Felker 1 sibling, 0 replies; 7+ messages in thread From: Rich Felker @ 2014-11-02 4:48 UTC (permalink / raw) To: musl On Sat, Nov 01, 2014 at 01:02:36PM -0400, Rich Felker wrote: > 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. I think we should do this, but while looking at how, I noticed a couple other issues: 1. Useless declaration of memcpy, which is unused. 2. Use of memset without a declaration. Just making a note here so I don't overlook these when fixing it. Rich ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-11-02 4:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-31 3:03 the prototype decl of memcpy/memcmp/calloc/free should not in sched.h 黄建忠 2014-10-31 3:24 ` Rich Felker 2014-10-31 3:42 ` the prototype decl of memcpy/memcmp/calloc/free shouldnot " 黄建忠 2014-11-01 16:22 ` Szabolcs Nagy 2014-11-01 17:02 ` Rich Felker 2014-11-01 20:49 ` Alexander Monakov 2014-11-02 4:48 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).