Opened 12 months ago

Last modified 12 months ago

#18407 new enhancement

C Locale support

Reported by: nephele Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: System/POSIX Version: R1/Development
Keywords: Cc: pulkomandy
Blocked By: Blocking:
Platform: All

Description

Should the "C" locale be added as an alias to the POSIX locale?

Posix sais this: "However, in a conforming POSIX implementation, the POSIX locale and the C locale are identical." https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html

It sounds to me like it is expected that the C locale is available and points to the POSIX locale. mpv seems to choke on this for example

Change History (6)

comment:1 by nephele, 12 months ago

locale -a does not list the C locale, and mpv fails with a call to set this apparently.

From mpv: https://github.com/mpv-player/mpv/blob/master/player/main.c#L239

// We mostly care about LC_NUMERIC, and how "." vs. "," is treated,
// Other locale stuff might break too, but probably isn't too bad.
static bool check_locale(void)
{
    char *name = setlocale(LC_NUMERIC, NULL);
    return !name || strcmp(name, "C") == 0 || strcmp(name, "C.UTF-8") == 0;
}

struct MPContext *mp_create(void)
{
    if (!check_locale()) {
        // Normally, we never print anything (except if the "terminal" option
        // is enabled), so this is an exception.
        fprintf(stderr, "Non-C locale detected. This is not supported.\n"
                        "Call 'setlocale(LC_NUMERIC, \"C\");' in your code.\n");
        return NULL;
    }
   [...]

Although looking at it more, i think mpv should likely check for POSIX there, too.

comment:2 by nephele, 12 months ago

Type: bugenhancement

comment:3 by waddlesplash, 12 months ago

Do you have a minimum test program here?

Is the set locale really the "POSIX" one indeed?

comment:4 by pulkomandy, 12 months ago

From the spec:

The strings "C" and "POSIX" are reserved as identifiers for the POSIX locale

And here: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_02 it says that it should be the default if nothing is set (from setlocale or environment variables). But it doesn't quite work this way for us since we set it from the Locale preferences instead?

comment:5 by nephele, 12 months ago

I think this is only relevant to programms written in C on startup.

For C-language programs, the POSIX locale shall be the default locale when the setlocale() function is not called

I had opened this ticket after talking with mpv devs, but to me it sounds like implementing "POSIX" as default is perfectly fine, following posix, this disagrees with the C language spec which wants "C" instead but we can't follow both at the same time.

In any case mpv only wanted this in the first place because the library they use to play files in archives is horribly broken with locales, but it is not used in haikuports port of mpv.

Implementing "C" would still not make this case for mpv work as posix still specifies POSIX as default and not "C"

comment:6 by pulkomandy, 12 months ago

There are multiple problems I can see.

The POSIX locale is the default global locale at entry to main().

Is this the case on Haiku? Does setlocale return "POSIX"? Or does it return the locale from Locale preferences?

It is not clear what setlocale(..., NULL) returns for the default locale

It could be "C", or "POSIX", or something else. At least I don't see anything in the POSIX spec that enforces the result of setlocale(..., NULL) to have any specific format, the only guarantee is that you can use the resulting string in another call to setlocale to restore the initial locale.

So, for the first problem we may be at fault, but for the second, I think it is MPV using behavior that is in fact not guaranteed by POSIX (even if it would make sense). And perhaps we should report a bug to POSIX (they have a bugtracker at https://www.austingroupbugs.net/main_page.php) to suggest clarifying their documentation for this case (and say that "POSIX" should be returned, or "C", or maybe both are possible and apps have to check both).

Note: See TracTickets for help on using tickets.