On 1/2/22 16:28, Bernhard Voelker wrote:
1073741858: that's 2^30 +34
Could it be an address, or part of an address, that is incorrectly
treated as an integer? A mistake like that is quite plausible given the
"does it return char * or int?" API of strerror_r.
On 1/2/22 21:46, Bruno Haible wrote:
> Bernhard Voelker wrote:
>> The error in the test-suite.log shows:
>>
>> FAIL: test-strerror_r
>> =
>>
>> test-strerror_r.c:112: assertion 'ret == ERANGE || ret == EINVAL' failed
>> FAIL test-strerror_r (exit status: 134)
>>
>
> I s
On 03 Jan 2022 00:26, Bernhard Voelker wrote:
> Comparing some of the license headers, I found that some modules are using a
> comma or
> a semicolon in the 3rd line of the text:
>
> $ ~/gnulib> GIT_PAGER= git grep -B2 -A1 'either version' -- doc/gpl-3.0.texi
> doc/gpl-3.0.texi-This program i
On 1/3/22 00:46, Bruno Haible wrote:
> Bernhard Voelker wrote:
>> Comparing some of the license headers, I found that some modules are using a
>> comma or
>> a semicolon in the 3rd line of the text:
>
> Why would that matter?
>
> I'm all for having clear and unambiguous license headers. But whet
Bernhard Voelker wrote:
> Comparing some of the license headers, I found that some modules are using a
> comma or
> a semicolon in the 3rd line of the text:
Why would that matter?
I'm all for having clear and unambiguous license headers. But whether there is
a comma or a semicolon here, does not
Paul Eggert wrote:
> I'd like to try the approach a bit more (especially as this prompted me
> to simplify it a bit :-). So I installed the first attached patch to
> Gnulib, to work around the bug in BusyBox 'sed'.
Thanks. I confirm that it works on Alpine Linux. Unlike me, you succeeded
in keep
Comparing some of the license headers, I found that some modules are using a
comma or
a semicolon in the 3rd line of the text:
$ ~/gnulib> GIT_PAGER= git grep -B2 -A1 'either version' -- doc/gpl-3.0.texi
doc/gpl-3.0.texi-This program is free software: you can redistribute it
and/or modify
Bernhard Voelker wrote:
> The error in the test-suite.log shows:
>
> FAIL: test-strerror_r
> =
>
> test-strerror_r.c:112: assertion 'ret == ERANGE || ret == EINVAL' failed
> FAIL test-strerror_r (exit status: 134)
>
I see this same test failure also on older glibc/Li
> 2022-01-01 Bruno Haible
>
> striconveh: Support an error handler that produces a Unicode U+FFFD.
The unit test fails on musl libc. This patch fixes it.
2022-01-02 Bruno Haible
striconveh: Make the last change also work on musl libc.
* lib/striconveh.c (mem_cd_icon
