Bruno Haible wrote:
> Jim Meyering wrote about modifications done to .gitignore files:
>> I've Cc'd bug-gnulib, since gnulib-tool appears
>> to be doing it.
>>
>> I notice that some of your differences appear to be due to sorting
>> with a different locale than I use. That implies there's a second
On IRIX 6.5, strerror(-1) returns NULL but perror("") for errno
of -1 prints "Unknown error"; POSIX requires that the two must
match, so we must replace perror. But since IRIX also lacks
strerror_r, our probe for a working [__xpg_]strerror_r was
never even happening.
* m4/perror.m4 (gl_FUNC_PERRO
Jim Meyering wrote about modifications done to .gitignore files:
> I've Cc'd bug-gnulib, since gnulib-tool appears
> to be doing it.
>
> I notice that some of your differences appear to be due to sorting
> with a different locale than I use. That implies there's a second
> problem: perhaps one of
On 06/21/11 12:43, Ralf Wildenhues wrote:
> It would be good to make sure GCC 4.6 whole program/link time
> optimization doesn't defeat this
It doesn't, at least, not on my platform (Fedora 14 x86-64 + GCC 4.6.0).
* Paul Eggert wrote on Tue, Jun 21, 2011 at 12:19:25AM CEST:
> Testing this is not something for the fainthearted, as it requires
> access to all sorts of strange hosts. However, it does seem to
> defeat GCC 4.6.0's tail-recursion optimization (-O0 through -O4)
> on my platform, which is what is w
Jim Meyering wrote:
...
>> $ git diff
>> diff --git a/.gitignore b/.gitignore
>> index 04320a6..818afc1 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -1,8 +1,3 @@
>> -!/gnulib-tests/Makefile.am
>> -!/lib/Makefile.am
>> -!/lib/savedir.c
>> -!/lib/savedir.h
>> -!/m4/djgpp
On 06/19/2011 03:06 AM, Bruno Haible wrote:
>> 2 x FAIL: test-strerror_r
>
> On Cygwin 1.7.9 (but not 1.7.5):
>
> test-strerror_r.c:78: assertion failed
>
> i = 1, ret = 0, buf = "BADFACE"
>
> Looks really like a Cygwin bug: You pass a positive buffer size, it returns 0
> but writes nothi
On 06/18/2011 06:59 PM, Bruno Haible wrote:
> Eric,
>
> Here's some info about the test-perror2 failures:
>
>> 3 x FAIL: test-perror2
>
> All three failures at line 112: ASSERT (strstr (buf, err));
>
> On OpenBSD 4.9:
>
> i = 1, err = "Success", buf = "Undefined error: 0\n"
Should now b
OpenBSD treats strerror_r(0,,) as a success, but with a message
"Undefined error: 0"; while this is distinct from strerror_r(-1,,)
returning "Unknown error: -1", it does not imply success. Meanwhile,
if buf is short enough for ERANGE, then we can't use strstr to look
for "Unknown" or "Undefined" i
On OpenBSD, strerror_r(1000,buf,19) gives "Unknown error: " rather
than "Unknown error: 100" while failing with ERANGE. Admittedly,
this behavior is nice, since a truncated integer is misleading,
but all other platforms use maximal strings on ERANGE and we are
already replacing strerror_r for othe
On OpenBSD, strerror_r(1000,buf,19) gives "Unknown error: " rather
than "Unknown error: 100" while failing with ERANGE. Admittedly,
this behavior is nice, since a truncated integer is misleading,
but all other platforms use maximal strings on ERANGE and we are
already replacing strerror_r for othe
Stefano Lattarini wrote:
> On Tuesday 21 June 2011, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>> ...
>> >> FYI, I've just pushed the following.
>> >> Now, I expect to tag grep-2.9 and release later today.
>> >> Last chance...
>> >>
>> > On NetBSD 5.1, I'm seeing this failure by running `make
If we ever adjust strerror-override.h to have a larger size for
STACKBUF_LEN, then perror should also pick up the adjustment.
* modules/perror (Depends-on): Add strerror-override.
* lib/perror.c (perror): Use it to avoid magic number.
Signed-off-by: Eric Blake
---
I'm pushing these two cleanups
* lib/strerror-override.c (strerror_override): Use fewer lines.
Signed-off-by: Eric Blake
---
Should be no functional change.
ChangeLog |5 +
lib/strerror-override.c | 271 +--
2 files changed, 100 insertions(+), 176 deletions(-)
Eric Blake wrote:
> [adding coreutils]
>
> On 06/20/2011 10:51 PM, Jim Meyering wrote:
2011-06-20 Bruno Haible
pathmax: Never define PATH_MAX to a non-constant expression.
* lib/pathmax.h (PATH_MAX): Don't define in terms of pathconf.
* m4/pathmax.m4 (gl_PATHMA
On 06/21/2011 03:50 AM, James Youngman wrote:
> On Mon, Jun 20, 2011 at 11:34 PM, Bruno Haible wrote:
>> I find it reasonable to use "#ifdef PATH_MAX" in front of every use of
>> PATH_MAX, like POSIX requires.
>
> I agree.
>
> I think it would be helpful if there were some automated way of
> rem
[adding coreutils]
On 06/20/2011 10:51 PM, Jim Meyering wrote:
>>> 2011-06-20 Bruno Haible
>>>
>>> pathmax: Never define PATH_MAX to a non-constant expression.
>>> * lib/pathmax.h (PATH_MAX): Don't define in terms of pathconf.
>>> * m4/pathmax.m4 (gl_PATHMAX): Don't test for pathcon
On Mon, Jun 20, 2011 at 11:34 PM, Bruno Haible wrote:
> I find it reasonable to use "#ifdef PATH_MAX" in front of every use of
> PATH_MAX, like POSIX requires.
I agree.
I think it would be helpful if there were some automated way of
reminding people to do that though. Many people develop on sys
18 matches
Mail list logo
