[Toybox] toybox ebuild.

[Rob Landley]

On 2/13/23 18:49, enh wrote:
> On Mon, Feb 13, 2023 at 4:41 PM Rob Landley <rob at landley.net> wrote:
>>
>> On 2/13/23 11:09, enh wrote:
>> > On Mon, Feb 13, 2023 at 1:07 AM Rob Landley <rob at landley.net> wrote:
>> >> >> Oh goddess why is it doing uselocale(newlocale()), I think it was a macos thing?
>> >> >> Yeah, git annotate says commit 4786fd610 which was Elliott. (Do you remember why
>> >> >> it was doing that?)
>> >> >
>> >> > because there isn't a C.UTF-8 (no matter how you try to spell it!) on
>> >> > macOS, so we need to "merge" utf-8-ness into the current locale. (i'd
>> >>
>> >> That isn't what  the  man page for newlocale() says we're doing, though?
>> >> newlocale(FLAG, "NAME", 0) is creating a new locale that's a subset of the
>> >> "NAME" locale, and the 0 means locale elements we don't give a flag for are
>> >> copied from the "POSIX" locale. (Which should be a synonym for "C".)
>> >
>> > i don't think so? that's not how i read
>> > https://pubs.opengroup.org/onlinepubs/9699919799/functions/newlocale.html
>> > anyway. i think it comes down to how you interpret "default locale"? i
>> > read it as equivalent to "", but you think it means "POSIX". i think
>> > POSIX agrees with me though? (search for "default locale" on
>> > https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
>> > for their definition. this is why we call setlocale() in that code,
>> > fwiw.)
>>
>> I was going by https://man7.org/linux/man-pages/man3/newlocale.3.html
>>
>>        For  each category specified in category_mask, the locale data from lo‐
>>        cale will be used in the object returned by newlocale().  If a new  lo‐
>>        cale  object is being created, data for all categories not specified in
>>        category_mask is taken from the default ("POSIX") locale.
> 
> i think the man7 page is just a slightly mangled version of the POSIX page?

"Data for all categories not specified in category_mask is taken from the POSIX
locale."

>> It's entirely possible bionic and glibc are doing different things here. I
>> wonder what musl is doing? (Alas, got my eyes dilated for an eye exam today, so
>> not digging through code to try to find out just now...)
> 
> bionic does nothing --- it doesn't believe in non-UTF8, and it doesn't
> believe in non-C. so no matter what you do, you end up with C.UTF-8.

It's any _other_ locale stuff, ala that date %x thing, which will drop any uk_UA
base info from the environment variables if that locale wasn't UTF8.

The call to newlocale() with the flags smells like a NOP, because we're saying
"take this from C.utf8, and the rest from C". We might as well just switch
locale to C.utf8 entirely because that's what the man page says we're de-facto
doing.

> i don't know about glibc, but at a quick glance i think musl agrees
> with my interpretation?

So works on bionic, works on musl, might not work on glibc?

Eh, might try something in portability.c at some point, but not a priority...

>> Rob

Rob