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
signature.asc
Description: PGP signature
