Re: diacrit: mark deprecated

2019-01-20 Thread Jim Meyering
On Sun, Jan 20, 2019 at 5:11 PM Bruno Haible wrote: > Hi Jim, > > You are listed as the maintainer of the 'diacrit' module. It doubt anyone is > still using this module, because it assumes an 8-bit character set, whereas > most systems have switched to UTF-8 10 to 18 years ago. Do you agree to

diacrit: mark deprecated

2019-01-20 Thread Bruno Haible
Hi Jim, You are listed as the maintainer of the 'diacrit' module. It doubt anyone is still using this module, because it assumes an 8-bit character set, whereas most systems have switched to UTF-8 10 to 18 years ago. Do you agree to mark it deprecated? diff --git a/modules/diacrit

work around inaccurate 'long double' math functions on NetBSD

2019-01-20 Thread Bruno Haible
On NetBSD 8.0 (x86_64, x86, and sparc64) I'm seeing test failures: FAIL: test-exp2l FAIL: test-expl FAIL: test-expm1l FAIL: test-log10l FAIL: test-log1pl FAIL: test-log2l FAIL: test-logl The results have apparently only 54 bits of precision, even though 'long double' has 64 or 113 bits of

floor, floorl: Avoid autoconf warnings

2019-01-20 Thread Bruno Haible
While creating a testdir $ ./gnulib-tool --create-testdir --dir=... --single-configure exp2l expl expm1l log10l log1pl log2l logl rintl I see two autoconf warnings: executing autoconf configure.ac:362: warning: AC_REQUIRE: `gl_FUNC_FLOORL' was expanded before it was required configure.ac:362:

Defeat current GCC optimizations in math autoconf tests

2019-01-20 Thread Bruno Haible
The attached program, when compiled with "gcc -O2" (gcc version >= 4.4), returns with exit code 0 without ever invoking the exp2l() function. Apparently GCC knows about identities for functions. A 'volatile' keyword is necessary to disable these identity-based optimizations. For reliability, add

Re: VLA and alloca

2019-01-20 Thread Pádraig Brady
On 20/01/19 02:19, Bruno Haible wrote: > Paul, > > Pádraig Brady wrote: >> I've pushed this with some comments at the current single GNULIB_NO_VLA >> usage. > > How about making use of this GNULIB_NO_VLA macro in all places that assume > VLA syntax? I'm proposing this patch: > > > 2019-01-20

Re: VLA and alloca

2019-01-20 Thread Bruno Haible
Pádraig Brady wrote: > I've not analyzed the security concerns in detail, but in general > large allocations on the stack are bad for security Indeed. Just reading this CVE [1] from a week ago, makes me want to disable all large allocations on the stack. Bruno [1]

Re: VLA and alloca

2019-01-20 Thread Bruno Haible
Paul, Pádraig Brady wrote: > I've pushed this with some comments at the current single GNULIB_NO_VLA usage. How about making use of this GNULIB_NO_VLA macro in all places that assume VLA syntax? I'm proposing this patch: 2019-01-20 Bruno Haible vla: Consider GNULIB_NO_VLA.

Re: bug#34141: Stackoverflow triggered at lib/regexec.c:1948

2019-01-20 Thread Assaf Gordon
(forwarding to gnulib) Hello, Hongxu Chen reported a stack-overflow in regexec. I suspect it is the same as the one reported here: https://lists.gnu.org/r/bug-gnulib/2018-09/msg00066.html But just in case, the full report is below. regards, - assaf On 2019-01-19 10:58 p.m., Hongxu Chen

Re: bug#34142: AddressSanitizer reported heap-buffer-overflow

2019-01-20 Thread Assaf Gordon
(forwarding to gnulib) Hello, Hongxu Chen reported a heap-buffer-overflow in gnulib's regexec code. It can be reproduced with current sed using: git clone git://git.sv.gnu.org/sed.git cd sed ./bootstrap && ./configure make build-asan echo 00 |