This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 15 Dec 2016 13:16, Wilco Dijkstra wrote: > Mike Frysinger wrote: > > On 13 Dec 2016 09:24, Wilco Dijkstra wrote: > > > Mike Frysinger wrote: > > > > we aren't doing this for many other mem/str funcs. why should we do it > > > > for these two ? we should be all in, or not do any. imo, we should just > > > > omit them and be done unless there is strong/compelling evidence to show > > > > otherwise. if the only point is to support old/uncommon config combos, > > > > then that isn't a great reason imo. > > > > > A similar redirection is done for several other functions, including mempcpy, stpcpy > > > and bzero. The namespace issue only exists for non-C90 functions that are used > > > inside GLIBC, so a small subset of all supported functions. > > > > i think you're conflating those here. if you look closely, it's for C++ > > code only, and it's because the signature is different (const-vs-non-const > > return). it's not for the reason you're doing a #define here. > > No I'm not talking about the C++ const inlines, I mean redirects to avoid namespace > issues (and to enable GCC to optimize builtins) for non-C90 functions that are used > inside GLIBC. Eg: i was getting hung up on the __builtin_xxx aspect. the redirects you're referring to don't involve those. doing a redirect to a diff glibc symbol is fine in the internal header. i don't really have an opinion on the style (define-vs-alias). -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |