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
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
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
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:
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
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
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]
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.
(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
(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 |
10 matches
Mail list logo