Re: Portability issue for error_tail().

Bruno Haible wrote: > Jim Meyering wrote: >> IMHO the latter (enhancing gcc) makes more sense. > > OK, I've reported it as a GCC bug here: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154 Thanks!

Re: Portability issue for error_tail().

Jim Meyering wrote: > IMHO the latter (enhancing gcc) makes more sense. OK, I've reported it as a GCC bug here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50154 Bruno -- In memoriam Alexander Bessmertny

Re: Portability issue for error_tail().

Bruno Haible wrote: > Paul Eggert wrote: >> portable programs should not pass a NULL format to 'error', so this is not >> a gnulib bug. > > Yes. But why does it not yield a GCC warning? > > foo.c = > #include > #include > extern void error (int __

Re: Portability issue for error_tail().

Paul Eggert wrote: > portable programs should not pass a NULL format to 'error', so this is not > a gnulib bug. Yes. But why does it not yield a GCC warning? foo.c = #include #include extern void error (int __status, int __errnum, __const char *_

Re: Portability issue for error_tail().

On 08/18/2011 06:11 PM, Mats Erik Andersson wrote: >error (EXIT_FAILURE, EPERM, NULL); > > nothing serious will happen on GNU/Linux with Glibc, My kneejerk reaction is that 'error' isn't documented to treat NULL as the empty string, and that portable programs should not pass a NULL format to

Portability issue for error_tail().

Dear all, I have found an exceptional portability issue when building GNU lib for NexentaCore/i386-pc-solaris2.11. Said system lacks the library call error (status, errno, format, ...) which therefore is brought in from GNU lib. However, should a programmer happen to erroneously write e