curl / Mailing Lists / curl-library / Single Mail


Setting locale based on env vars in Windows - feedback needed

From: Ray Satiro via curl-library <>
Date: Wed, 15 Mar 2017 13:18:34 -0400

Several months ago it was reported that setting environment variable
LC_ALL=C did not work for native Windows builds of curl [1]. The C
standard does not require reading from env var LC_ALL, and MS CRT
doesn't appear to do it though cygwin CRT does.

The reporter uses Brazil locale which uses a comma to indicate decimal
place, but expected that by setting C locale via env var LC_ALL a period
would be used for decimal place. His example:

$ LC_ALL=C curl --silent --output /dev/nul --write-out "Total time:
Total time: 0,609

curl currently sets calls setlocale to set LC_ALL to "" [2] which
according to the C standard is the implementation defined native
environment. It does not check the environment variables of LC_ALL or
any LC_*, I guess figuring the CRT has done that. Since MS CRT does not
do it I made a patch [3] that pulls from env var LANG to set the LCs:

I'm not 100% on it because I'm concerned it could cause more problems
than it solves and introduce more inconsistency. The locale strings that
are valid in MS CRT vary depending on version [4], for example VS2010 MS
CRT uses different strings than VS 2012. Also, some people could have
software that when installed decided to set its own LANG or LC_ALL in
the environment, etc, and so users may now have scripts that don't
expect curl will pick up on that. For example existing scripts parsing
statistics start to malfunction. Or the opposite, writing a script
against one version of curl and then some older version is used and the
script malfunctions.

What do you think of the patch? Would a switch be better instead like
--force-lang or --force-locale ? Or maybe this should be abandoned
entirely, since in several years this is the first I'm hearing of this.


Received on 2017-03-15