extended locale extentions

extended locale extentions

[aep]

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.

Re: extended locale extentions

[Szabolcs Nagy]

* 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)

Re: extended locale extentions

[aep]

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.

Re: extended locale extentions

[Rich Felker]

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