JTC1/SC22/WG14 N677

                    Document Number:  WG14 N677/X3J11 97-040

                              Locales and Conformance


Abstract
========

DR065 addressed the issues of the level of conformance of code that
generates different results according to which locales are available and
their content, but does not rely on the presence of a specific locale
other than "C" and "".

The response suggested that this issue should be revisited when the
Standard is revised.


The original DR
===============

The original DR gave the following example program:

    #include <stdio.h>
    #include <stdlib.h>
    #include <locale.h>

    int main (void)
    {
        int i;
        char *loc [] = { "English", "En_UK", "Loglan", "" };

        for (i = 0; ; i++)
            if (setlocale (LC_ALL, loc [i]) != NULL)
            {
                printf ("Decimal point = '%s'\n",
                        localeconv ()->>decimal_point);
                exit (0);
        }
    }

As can be seen, this program tries various locales in turn until it
finds one that is defined, and then takes some action based on its
contents. The last entry in the list - "" - is always a valid argument
to setlocale(), and so the printf() call must eventually be executed.
The DR asked:

|| The valid locales are implementation-defined (subclause 7.4.1.1).
|| Nevertheless, the output produced depends only on the locale, not any
|| other implementation-defined behavior. Is the program strictly
|| conforming?

In response, WG14 stated that the code was intended to be strictly
conforming. While the behaviour is locale specific, and varies according
to the "implementation-defined" presence or absence of various named
locales, it does not rely on the presence of locales other than "C" and
"".

|| Nevertheless, it is agreed that the cited extract from subclause
|| 7.4.1.1 could be read strictly as making such programs depend on
|| implementation-defined behavior.

|| The Committee reaffirms that programs that depend on the identity of
|| the available locales, as opposed to their contents, are not strictly
|| conforming.

In an attempt to clarify the matter without completely revamping the
conformance requirements of the Standard, TC2 changed the following
occurrences of "implementation-defined" to "locale-specific":

[references are relative to draft 9 pre 3]

Subclause 5.2.1.2, third bullet item
Subclause 7.3 paragraph 2
Subclause 7.3.1.2 (isalpha()), paragraph 2
Subclause 7.3.1.6 (islower()), paragraph 2
Subclause 7.3.1.9 (isspace()), paragraph 2
Subclause 7.3.1.10 (isupper()), paragraph 2
Subclause 7.5.1.1 (setlocale()) paragraph 3
Subclause 7.13.1.5 (strtod()) paragraph 5
Subclause 7.13.1.6 (strtol()) paragraph 6
Subclause 7.13.1.8 (strtoul()) paragraph 6
Footnote 195 (subclause 7.13.7)
Subclause 7.14.6.2 (strerror()), paragraph 4
Some material was moved from Annex I.3 to I.4.

Finally, the response suggested that this issue should be revisited when
the Standard is revised.


Outline proposal
================

Add wording to clause 4, clarifying that a strictly-conforming program
may produce output depending on locale-specific behaviour, and on the
presence or absence of specific locales, provided that it does not
invoke undefined, unspecified, or implementation-defined behaviour when
a given locale appears or disappears, or changes its value.

[Reading this paragraph again, I can see that some wordsmithing will be
needed.]

Example: the above program is strictly-conforming. If the empty string
is removed from the list, then it is not strictly-conforming, because it
invokes undefined behaviour if none of the named locales exist.

Example: a program that assumes "strlen(localeconv()->thousands_sep)" is
less than 2 is strictly conforming, because this is implied by the use
of the term "character" in the definition. A program that divides by the
value returned by that call to strlen() is not, because undefined
behaviour is invoked in some locales.


Most of the changed wording is more accurate than the original form.
However, one case reads awkwardly: in subclause 7.5.1.1 paragraph 3, the
term "locale-specific" should revert to "implementation-defined". Though
this wording was the target of the original DR, the change suggested
above would remove any ambiguity in the meaning of this paragraph.

Incidentally, neither I.3 nor I.4 appears to refer to this paragraph.

-- 
Clive D.W. Feather    | Associate Director  | Director
Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd.
Fax: +44 181 371 1150 | <clive@demon.net>   | <cdwf@cityscape.co.uk>
Written on my laptop - please reply to the Reply-To address <clive@demon.net>