Re: z/OS, iconv, and charset aliases

> 2019-12-19 Bruno Haible > > iconv tests: Test canonicalized, not system-dependent, encoding names. > * tests/test-iconv.c (main): Revert part of the 2016-08-17 patch. Addendum: * modules/iconv-tests (Depends-on): Add iconv_open. diff --git a/modules/iconv-tests b/module

Re: z/OS, iconv, and charset aliases

Hi Daniel, In you submitted this patch, which Paul committed on 2016-08-18: > Also, iconv_open() on > z/OS does not recognize "ISO-8859-1", but "ISO8859-1" works. diff --git a/tests/test-iconv.c b/tests/test-iconv.c index ed71

Re: z/OS configure triple

Hi Daniel, In you wrote: > gnulib-zos-configure.patch: Changes to the Autoconf M4 code to support > z/OS. What is the host_os of the canonical triple in that environment? Is it 'mvs' or 'openedition'? I know that at the C prep

localename: fix test failure on AIX 7.2

On AIX 7.2 I see this test failure: FAIL: test-localename ../../gltests/test-localename.c:211: assertion 'strcmp (name, "fr_FR.UTF-8") == 0' failed The reason is that AIX does not give access to the names of the categories in a locale_t object - neither through nl_langinfo, nor through internals

Re: Compiler warning with Oracle Developer Studio 12.6

On 12/18/19 4:49 PM, Bruno Haible wrote: if you want to fix this warning: Good patches are welcome. Having a bit of a soft spot for Solaris-based systems, I installed the attached. It fixes the warning for me and is obviously safe for typical (i.e., !__SUNPRO_CC) platforms. >From 876946f8d98e

Re: Compiler warning with Oracle Developer Studio 12.6

Hi Christian, > I tried compiling with /opt/developerstudio12.6/bin/CC on gcc211 > (basically the newer version of Sun CC, I think), and am getting > warnings like this: > > "../gnulib/import/../../gnulib/config.h", line 1346: Warning > (Anachronism): Attempt to redefine __restrict__ without usin

Compiler warning with Oracle Developer Studio 12.6

Hi there! I tried compiling with /opt/developerstudio12.6/bin/CC on gcc211 (basically the newer version of Sun CC, I think), and am getting warnings like this: "../gnulib/import/../../gnulib/config.h", line 1346: Warning (Anachronism): Attempt to redefine __restrict__ without using #undef. Fairl

Re: sv_SE locale

Bruno Haible writes: > Paul Eggert wrote: >> When we have time we are trying to move >> Gnulib and Glibc back to the original meaning. Code fixes to that effect >> would be welcome (both in Gnulib and in Glibc, I expect). > > Here are three relevant tickets in the glibc bug tracker: > https://s

Re: sv_SE locale

Paul Eggert wrote: > When we have time we are trying to move > Gnulib and Glibc back to the original meaning. Code fixes to that effect > would be welcome (both in Gnulib and in Glibc, I expect). Here are three relevant tickets in the glibc bug tracker: https://sourceware.org/bugzilla/show_bug.c

Re: sv_SE locale

On 12/18/19 12:21 PM, moos...@gmail.com wrote: glibc and gnulib behave differently when sv_SE is in effect, the standard (I believe) leaves the behavior unspecified (undefined?) Still The difference is suprising (at least it was to me). Perheaps someone here can comment on the issue? Traditiona

sv_SE locale

glibc and gnulib behave differently when sv_SE is in effect, the standard (I believe) leaves the behavior unspecified (undefined?) Still The difference is suprising (at least it was to me). Perheaps someone here can comment on the issue? http://ix.io/1Xa4

Re: Compile error with xlclang++ on AIX

On 2019-12-07 I pushed: > * lib/wchar.in.h (mbstate_t): Don't override on AIX. This caused a regression: mbrtowc tests started to fail on AIX and, later, also on MSVC. This patch fixes the regression: 2019-12-18 Bruno Haible wchar: Fix test failures on AIX and MSVC (regression

Re: [PATCH 4/4] dfa: do not match invalid UTF-8

On 12/18/19 12:48 AM, Bruno Haible wrote re my recent Gnulib change , with corresponding Grep change : >

Re: LC_COLLATE in the C locale

On 12/18/19 2:29 AM, Bruno Haible wrote: > Hi Paul, > >> I do have a qualm in that coreutils (and I assume others) interpret >> !hard_locale >> (LC_COLLATE) as meaning that the locale is unibyte and uses native byte >> comparison. > Isn't this warranted by section "LC_COLLATE Category in the POSI

localename: ensure multithread-safety in future changes

This patch makes sure we don't use MT-unsafe primitives in future changes of module 'localename'. - In function get_locale_t_name - currently not used on any platform, because it's in a #if HAVE_NAMELESS_LOCALES - it's better to use the MT-safe setlocale_null. - In function gl_locale_name_pos

Re: setlocale: make calls with NULL argument multithread-safe

Part of this new code in setlocale.c would also be useful for localename.c. I'm therefore moving it to module 'setlocale-null'. At the same time, I'm renaming the function setlocale_null to setlocale_null_r (in analogy with getlogin_r, ttyname_r, ptsname_r). 2019-12-18 Bruno Haible se

localename: optimize code for native Windows

This piece of code in localename.c const char *locname = setlocale (category, NULL); LCID lcid; /* If CATEGORY is LC_ALL, the result might be a semi-colon separated list of locales. We need only one, so we take the one corresponding to LC_CTYPE, as the most impo

setlocale: make calls with NULL argument multithread-safe

This patch makes use of the 'setlocale-null' module, to make the setlocale(..., NULL) calls multithread-safe. Use of setlocale(), with the gnulib override, now requires linking with $(LIB_SETLOCALE) - to avoid link errors on AIX. Although we now have two modules 'setlocale-null' and 'setlocale' w

Re: hard-locale: make multithread-safe

Paul Eggert wrote: > Thanks, this change looks fine to me. I'm pushing it. Tested: on all platforms, the unit test still passes. Additionally, the test failure on Android is gone. It adds a new link requirement for the users of this module. It's necessary because on AIX, -lpthread is necessary fo

Re: LC_COLLATE in the C locale

Hi Paul, > I do have a qualm in that coreutils (and I assume others) interpret > !hard_locale > (LC_COLLATE) as meaning that the locale is unibyte and uses native byte > comparison. Isn't this warranted by section "LC_COLLATE Category in the POSIX Locale" in

Re: new module 'setlocale-null'

setlocale (category, NULL)_can return NULL in two situations: - when the category argument is invalid, or - on Android (tested on Android 4.3). 2019-12-18 Bruno Haible setlocale-null: Handle NULL result from setlocale. * lib/locale.in.h (setlocale_null): Document EINVAL re

Re: dfa.c badly broken when dropped into gawk

Paul Eggert wrote: > On 12/15/19 10:43 AM, Arnold Robbins wrote: > > To reproduce: > > > > 1. Checkout the gawk repo > > 2. Copy gnulib/lib/dfa.[ch] into gawk/support/. > > 3. Apply the minimal patch below > > I looked into that, and the problem was not in Gnulib; it was that your > minimal patc

Re: hard-locale: make multithread-safe

> Thanks, this change looks fine to me. Thanks. But before I do the rewrite, let me add a unit test first. It's a bit tricky only on musl libc, NetBSD, and OpenBSD. Other than that, there's a test failure on Android 4.3, where - setlocale (category, NULL) always returns NULL. - hard_locale of

Re: [PATCH 4/4] dfa: do not match invalid UTF-8

Hi Paul, > (add_utf8_anychar): Match only valid UTF-8 byte sequences > instead of allowing overlong encodings or surrogate halves. Do I understand it correctly that, as a consequence of this change, 'grep' with a regex of '^.*$' will no longer match lines which contains an invalid UTF-8 byte sequ