lee@hcx1.SSD.HARRIS.COM (03/31/89)
I have read and re-read what I believe to be the current draft of the pANS C,
but I can't decide what the effect of the following code segment is really
supposed to be.
(1) struct lconv *lp;
(2) lp = localeconv();
(3) setlocale(LC_NUMERIC, "newlocale");
(4) printf("%s", lp->decimal_point);
(5) printf("%8.2f", floatnum);
(6) printf("%s", lp->decimal_point);
In other words, does setlocale affect the lconv structure as used by
library functions, and does it affect the structure to which I have a
pointer? If so, what is that effect?
The relevant passages from section 4.4.2.1 of the standard are these:
"The localeconv function sets the components of an object with type
struct lconv with values appropriate for the formatting of numeric
quantities (monetary and otherwise) according to the rules of the
current locale."
I can read into this that the three printfs above use the old locale
because a new localeconv call has yet to be made to "set the components".
However, I don't feel compelled to believe this interpretation.
Later, it says:
"The structure pointed to by the return value... may be overwritten by
a subsequent call to the localeconv function. In addition, calls to
the setlocale function... may overwrite the contents of the structure."
I think this means that there is no telling what my program will print.
It certainly allows an implementation of setlocale to change the structure
to which I have a pointer so that the printfs on (4,6) use the new locale,
but it doesn't seem to require that action due to the use of the word "may".
Similarly, a call to localeconv may change the structure, which would
indicate that the effects of a setlocale call may be delayed and that the
printfs on lines (4,6) would use the old locale.
But an important point is this:
"The implementation shall behave as if no library function calls the
localeconv function."
This means that if the printf on line (5) uses the new locale (which I
believe it must, because it has to call localeconv to get the decimal point
and a localeconv call will make sure that the structure is up to date),
then it must not share a copy of the lconv structure with me. If its call
to localeconv affects my copy of the structure, then the library is not
behaving itself.
I think there are these three possibilities:
(1) setlocale affects the structure to which I have a pointer and which
the library functions use. localeconv cannot modify the structure,
contrary to the suggestion in the "Returns" section of 4.4.2.1.
(2) setlocale does not affect my structure, nor that used by the library.
The effect is delayed until the localeconv. Calls to localeconv must
make a copy of the master structure, so that library functions are
well-behaved. (The copies, if malloc'ed, cannot be freed portably,
of course.) Setlocale cannot modify the structure, contrary to the
suggestion in the "Returns" section of 4.4.2.1.
(3) This is all implementation defined, and no application program should
call setlocale when it has already called localeconv unless it calls
localeconv again, immediately after the setlocale. In other words,
a call to setlocale causes a pointer obtained from localeconv to be
undefined. A call to a library function is then allowed to change
my structure from undefined to undefined-prime.
Which one is it? Does anyone care to propose a Ruling on this? Would
anyone like to share the details of any existing implementations?
--
Lee Brown, aka lee@ssd.harris.com or ...uunet!hcx1!lee
Harris Computer Systems Division