* extended locale extentions @ 2011-10-10 14:07 aep 2011-10-10 14:17 ` Szabolcs Nagy 0 siblings, 1 reply; 4+ messages in thread From: aep @ 2011-10-10 14:07 UTC (permalink / raw) To: musl Hey, anyone would be offended by adding the non standard locale extentions to musl? that is isspace_l, isupper_l , etc... They're not standard but pretty much every libc has them and libstdc++ unfortunately expects them. For a good reason too: otherwise it has to threadlock the c locale, which is painfully slow. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: extended locale extentions 2011-10-10 14:07 extended locale extentions aep @ 2011-10-10 14:17 ` Szabolcs Nagy 2011-10-10 14:25 ` aep 0 siblings, 1 reply; 4+ messages in thread From: Szabolcs Nagy @ 2011-10-10 14:17 UTC (permalink / raw) To: musl * aep <aep@exys.org> [2011-10-10 16:07:33 +0200]: > Hey, anyone would be offended by adding the non standard locale > extentions to musl? > > that is isspace_l, isupper_l , etc... > these are standard, not c standard, but posix standard http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ctype.h.html i wonder if a dummy implementation is ok eg #define foo_l(c, l) foo(c) (maybe with a check if l is the c/posix locale) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: extended locale extentions 2011-10-10 14:17 ` Szabolcs Nagy @ 2011-10-10 14:25 ` aep 2011-10-11 4:13 ` Rich Felker 0 siblings, 1 reply; 4+ messages in thread From: aep @ 2011-10-10 14:25 UTC (permalink / raw) To: musl On Mon, 10 Oct 2011 16:17:04 +0200, Szabolcs Nagy wrote: >> that is isspace_l, isupper_l , etc... > these are standard, not c standard, but posix standard i used the wrong examples. what i meant was strtol_l, strtoul_l, strtoll_l, possibly others... > i wonder if a dummy implementation is ok > eg > #define foo_l(c, l) foo(c) > (maybe with a check if l is the c/posix locale) that's pretty much what is there. It's good enough for me (as my use case only has one locale), but i was wondering if its ok before i work on a patch. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: extended locale extentions 2011-10-10 14:25 ` aep @ 2011-10-11 4:13 ` Rich Felker 0 siblings, 0 replies; 4+ messages in thread From: Rich Felker @ 2011-10-11 4:13 UTC (permalink / raw) To: musl On Mon, Oct 10, 2011 at 04:25:01PM +0200, aep wrote: > On Mon, 10 Oct 2011 16:17:04 +0200, Szabolcs Nagy wrote: > >>that is isspace_l, isupper_l , etc... > >these are standard, not c standard, but posix standard > > i used the wrong examples. what i meant was > strtol_l, strtoul_l, strtoll_l, possibly others... My thought for these, since they don't need to conform to any standard, is just to weak alias them as: weak_alias(strtol, strtol_l); etc. Obviously the types are wrong but it doesn't matter because they won't use the locale_t argument anyway, and as long as _GNU_SOURCE is not defined in the source file, the conflicting prototype in the header won't matter. > >i wonder if a dummy implementation is ok > >eg > >#define foo_l(c, l) foo(c) > >(maybe with a check if l is the c/posix locale) > > > that's pretty much what is there. It's good enough for me (as my use > case only has one locale), but i was wondering if its ok before i > work on a patch. Actually handling them with macros would probably work just as well... Rich ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-10-11 4:13 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-10-10 14:07 extended locale extentions aep 2011-10-10 14:17 ` Szabolcs Nagy 2011-10-10 14:25 ` aep 2011-10-11 4:13 ` 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).