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]

Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.6.0-0.9


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:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ctype.h.html

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

  #if __MISC_VISIBLE || __XSI_VISIBLE
  int _EXFUN(isascii, (int __c));
  int _EXFUN(toascii, (int __c));
  [...]
  #endif

> nl_langinfo_l(3) is in POSIX and is not included in your list:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/nl_langinfo.html

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
process-wide.

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
Cygwin.


Thanks,
Corinna

-- 
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]