This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


Hi Brian,

On Aug 19 13:06, Brian Inglis wrote:
> On 2016-08-19 09:31, Corinna Vinschen wrote:
> > I uploaded a new Cygwin test release 2.6.0-0.9.
> > The 2.6.0 release is going to introducing the locale_t datatype, as well
> > as all functions related to locale_t locales and per-thread locales per
> > POSIX-1.2008.
> > The full list of new interfaces is:
> >   isalnum_l, isalpha_l, *isascii_l*, isblank_l, iscntrl_l, isdigit_l,
> >   *toascii_l*, tolower_l, toupper_l, towctrans_l, towlower_l, towupper_l,
> Macros/functions isascii_l(3) and toascii_l(3) are not in POSIX,

Right, they are GNU extensions and marked as such in the headers.  But
you're right, I should have been more clear in the release message as to
which functions are POSIX and which ones are GNU extensions.

> and isascii(3) and toascii(3) are deprecated:

Right, and the feature test macros in ctype.h say so:

  int _EXFUN(isascii, (int __c));
  int _EXFUN(toascii, (int __c));

> nl_langinfo_l(3) is in POSIX and is not included in your list:

Right, thanks for pointing this out.  Oh well, I searched the POSIX
function list *at least* twice and simply didn't see this function.
I hope I didn't miss another one.

This will be rectified in the next test release which I'm going to
upload in a sec.

> Will LC_GLOBAL_LOCALE designate the locale -f or locale -n locale?

Neither.  LC_GLOBAL_LOCALE is a per process locale and per POSIX the
default is to set it to the "C" locale at process startup.  A POSIX
compliant application has to call setlocale(3) to change its locale

locale -f or locale -n are really only fetching information from Windows
when you call the tool, but the underlying WIndows functions are never
directly used by the Cygwin DLL.

You *can* use them to prime your locale-specific environment variables,
but that's all.  Cygwin applications default to the "C" locale, or to
the locales set via the LANG/LC_xxx variables *if* the application calls
setlocale(LC_ALL, NULL);

> locale -s and locale -u appear to return the Windows default product
> locale e.g. en_US, regardless of system default regional settings.

Not quite.  Let's have a look into the locale(1) options:

-i returns the current "input" language.  That's what you set in the
region&language settings and by choosing a locale for input in the
keyboard layout control.  This is often what you really want, but we
only found out about this a couple of days ago when we had a system with
-u persisting to return the wrong info.

-s and -u are a bit tricky.  Both depend on the installed language packs
which you can download from Microsoft.  If you didn't install another
language pack, then the *only* language ever returned by -s and -u will
be the language you installed the OS with in the first place.  Download
langauge packs and this gets settable, the -s option only by an admin,
of course.

-f is equivalent to the langauge you set the "Format" settings to, i. e.
the settings for date, time, monetary...

And last but not least -n is the locale used for applications which are
not UNICODE capable.  This affects the Windows API but it's not used by


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: signature.asc
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]