This particular header popped up about five years after work began on the standard. At that time, many of us felt that the standard was essentially complete. We were simply putting a few finishing touches on a product in which we had invested five years of our lives. Resistance was mounting to change of any sort.

I recall mentioning a change that I would have liked. (I forget now just what the change was.) In the interest of speeding closure, however, I suggested that the committee not make the change. An attendee from the UK, Keith Winter, also expressed support for the change. But he, too, was willing to let it slide. After all, he said, it was just one of many changes that would have to be made to the ISO standard for C.

Silence.

After we collected our collective wits, several of us simultaneously uttered the moral equivalent of, "Say what?" Winter went on to explain calmly that a number of Europeans were unhappy with certain parts of the C standard being developed by X3J11. It was simply too American in several critical ways. They despaired of trying to educate us insular Yanks about the needs of the world marketplace. Rather, they were content to wait and fight their battles on a more congenial field. The Europeans took it for granted that an ISO standard for C must differ from the ANSI standard.

Many of us disagreed with that position. We felt it imperative that whatever standard ANSI developed had to be acceptable to the international community. We had seen the effects in the past of computer language standards that differed around the world. Our five years of effort would be in vain, we felt, if the final word on C came from a separate committee second-guessing all our decisions.

So we sighed a deep sigh and asked the Europeans to show us their shopping list of changes. Most of the items on the list dealt with ways to adapt C programs to different cultures. That is a much more obvious problem in a land of many languages and nations such as Europe. Americans enjoy the luxury of a single (official) language and a fairly simple alphabet.

AT&T Bell Labs went so far as to host a special meeting to deal with various issues of internationalization. (This is a big word that people are uttering more and more often. It seems to have no acceptable synonym that is any shorter. The techie solution is to introduce the barbarism I18N, pronounced EYE eighteen EN. The 18 stands for the number of letters omitted.) Out of that meeting came the proposal for adding locale support to Standard C. The machinery eventually adopted is remarkably close to the original proposal.

Adding locales to C had the desired effect. Many of the objections to ANSI C as an international standard were derailed. It cost X3Jll an extra year, by my estimation, to hammer out locales. And we probably spent yet another year dealing with residual gripes from the international community. (And WG14, the ISO C standard committee, is still working on additions to the existing Standard.) Nevertheless, we succeeded in producing a standard for C that is currently identical at both ANSI and ISO levels.

The new process can simply ignore environment variables. It loses a few dozen, or a few hundred, bytes of storage that it might otherwise enjoy. Or it can look for certain environment variables and study their current values. A common variable is TZ, which provides information to the library date functions about the current time zone. If the value of TZ is, say, EST05E0T, the time functions know to label local standard time as EST and local daylight savings time as EDT. The local (standard) time zone is five hours later than UTC, known in the past as Greenwich Mean Time.

Environment variables have many uses. They are a great way to smuggle file names into an application program. It is almost always a bad idea to wire file names directly into a program. Prompting the user for file names is mostly a good idea, except for secret files about which the user should not have to be informed. Asking for such a file name on the command line that starts the program is somewhat better, but it can be a nuisance. It is a particular nuisance is several programs in a suite need access to the same file name. That's why it is often much nicer to set an environment variable to the file name once and for all in a script that starts a session. The file name is captured in one place, but is made available to a whole hierarchy of programs.

If you are at all literate about MS-DOS, you probably know that that system supports environment variables too. They are just one of many good ideas borrowed from past experience with UNIX. I have purchased several bits of commercial software that use environment variables to advantage. A common use is to locate special directories that contain support files or that are well-suited for hosting temporary files. But they have many other uses as well.

The Standard C library includes the function getenv. You will find it declared in the standard header <stdlib.h>. Call getenv with the name of an environment variable and it will return a pointer to its value string, if there is one. It is not considered an error to reference a variable that is not defined.

Note, however, that the Standard does not include setenv, the usual companion to getenv. That is the common name for the function that lets you alter the values associated with environment variables. Simply put, committee X3Jll couldn't decide how to describe the semantics of setenv. They differ too much among various single-user and multiprocessing systems. So you can write portable code that reads environment variables, but you can't alter them in a standard way.

When I talk about a culture, by the way, I don't mean just a group that speaks a common language. People in the USA write dates as 7/4/1776 (Independence Day). The same day in the UK is written as 4/7/1776 (Thanksgiving Day). Even within the USA, practices can vary. Where we civilians might write a debit as $-123.45, an accountant may well prefer (123.45).

For this reason, and others, locales have substructure. You can set an entire locale, or you can alter one or more categories. Separate categories exist for controlling collation sequences, character classification, monetary formatting, other numeric formatting, and times. The header <locale.h> defines several macros with names such as LC_COLLATE and LC_TIME. Each expands to an integer value that you can use as the category argument to setlocale, the function that alters locales. An implementation can choose to provide additional categories as well. A program that uses such added categories will, of course, be less portable than one that does not.

The idea behind categories is that an application may wish to tailor its locale. It may want to print dates in the local language and by the formatting rules of that language. But it may still opt to use the dot for a decimal point even though speakers of that language customarily write a comma. Or the application may adapt completely to a given locale, then change the monetary category to match a worldwide corporate standard for expressing accounting information.

Much of the information provided in a locale is purely informative. C has never treated currency amounts as a special data type. It is no surprise, therefore, that the Standard C library is unaffected by a change in the monetary category. On the other hand, some changes in locale very definitely affect how certain library functions behave. If a culture uses a comma for a decimal point, then the scanf family should accept commas and the printf family (and strtod) should produce commas in the proper places. That is indeed what happens.

Here are all the places where library behavior changes with locale:

• The functions strcoll and strxfrm in <string.h> can change how they collate when category LC_COLLATE changes.
• The functions in <ctype.h>, the printf and scanf families, and the numeric conversion functions in <stdlib.h>, can change how they test and alter certain characters when category LC_CTYPE changes.
• The multibyte character functions in <stdlib.h>, and the printf and scanf families, can change how they parse and translate multibyte strings when category LC_CTYPE changes.
• The printf and scanf families, and atof and strtod in <stdlib.h>, can change what they use for the decimal point character when category LC_NUMERIC changes.
• The strftime function in <time.h> can change how it converts times to character strings when category LC_TIME changes.
• The localeconv function in <locale.h> can change the information reported for the current locale when categories LC_MONETARY or LC_NUMERIC change.

X3Jll anguished about such issues when we spelled out the behavior of locales. We recognized that many people don't want to be bothered with this machinery at all. Those folks should suffer little from the addition of locales. Still others have only modest goals. They want to trade in the Americanisms wired into older C for conventions more in tune with their culture. Still others are ambitious. They want to write code that can be sold unchanged, in binary form, in numerous markets. That code must be very sophisticated about changing locales.

The simplest way to use locales is to ignore them. Every Standard C program starts up in the "C" locale. In this locale, the traditional library functions behave pretty much as they always have. islower returns a nonzero value only for the 26 letters of the English alphabet, for example. The decimal point is a dot. If your program never calls setlocale, none of this behavior can change.

The next simplest way to use locales is to change once, just after program startup, and leave it at that. The C Standard requires no other locale names besides "C". But it does define a defalut locale designated by the empty string "". If your program executes

setlocale (LC_ALL, "")

You must be more careful in using the library, once the locale can change on you. Some things get easier, such as displaying pretty dates or skipping the appropriate characters for white space. Other things get chancier, such as parsing strings with the functions in <ctype.h>. In a pinch, you can always revert part or all of the locale to the "C" locale, as in:

char *s1 = setlocale(LC_CTYPE, "C");
char *s2 = malloc(strlen(s1) + 1);
if (s2 == NULL)
    <despair>
strcpy(s2, s1);
<use ctype functions safely>
<setlocale(LC_ALL, s2);

I won't go into more sophisticated manipulation of locales at this point. That must wait until we have covered some of the implementation issues raised so far. You will find that they are dizzying enough in their own right.

The type is

struct lconv

char *decimal_point;      /*"." */
char *thousands_sep;      /* "" */
char *grouping;           /* "" */
char *int_curr_symbol;    /* "" */
char *currency_symbol;    /* "" */
char *mon_decimal_point;  /* "" */
char *mon_thousands_sep;  /* "" */
char *mon_grouping;       /* "" */
char *positive_sign;      /* "" */
char *negative_sign;      /* "" */
char int_frac_digits;     /* CHAR_MAX */
char frac_digits;         /* CHAR_MAX */
char p_cs_precedes;       /* CHAR_MAX */
char p_sep_by_space;      /* CHAR_MAX */
char n_cs_precedes;       /* CHAR_MAX */
char n_sep by_space;      /* CHAR_MAX */
char p_sign_posn;         /* CHAR_MAX */
char n_sign_posn;         /* CHAR_MAX */

LC_ALL
LC_COLLATE
LC_CTYPE
LC_MONETARY
LC_NUMERIC
LC_TIME

The second chunk you must read is the description of localeconv, the function that lets you query the current locale:

#include <locale.h>
struct lconv *localeconv(void);

The members of the structure with type char * are pointers to strings, any of which (except decimal_point) can point to "", to indicate that the value is not available in the current locale or is of zero length. The members with type char are non-negative numbers, any of which can be CHAR_MAX to indicate that the value is not available in the current locale. The members include the following:

char *decimal_point

char *thousands_sep

char *grouping

char *int_curr_symbol

char *currency_symbol

char *mon_decimal_point

char *mon_thousands_sep

char *man_grouping

char *positive_sign

char *negative_sign

char int_frac_digits

char frac_digits

char p_cs_precedes

char p_sep_by_space

char n_cs_precedes

char n_sep_by_space

char p_sign_posn

char n_sign_posn

The elements of grouping and mon_grouping are interpreted according to the following:

CHAR_MAX No further grouping is to be performed.

0 The previous element is to be repeatedly used for the remainder of the digits.

other The integer value is the number of digits that comprise the current group. The next element is examined to determine the size of the next group of digits before the current group.

The value of p_sign_posn and n_sign_posn is interpreted according to the following:

0 Parentheses surround the quantity and currency_symbol.

1 The sign string precedes the quantity and currency_symbol.

2 The sign string succeeds the quantity and currency_symbol.

3 The sign string immediately precedes the currency_symbol.

4 The sign string immediately succeeds the currency_symbol.

The implementation shall behave as if no library function calls the localeconv function.

Footnote:

100. See future library directions (4.13.3). [end of excerpt]