Eric Blake byu.net> writes:
> > > Meanwhile, is this patch acceptable, which updates the _LIBC
> > > portions of the error module to resemble CVS glibc more closely, so
> > > that I have fewer spurious diffs to filter through?
> >
> > Yes, and thanks for doing some of this (normally-thankless) t
Paul Eggert CS.UCLA.EDU> writes:
>
> Eric Blake byu.net> writes:
>
> > Meanwhile, is this patch acceptable, which updates the _LIBC
> > portions of the error module to resemble CVS glibc more closely, so
> > that I have fewer spurious diffs to filter through?
>
> Yes, and thanks for doing som
Eric Blake <[EMAIL PROTECTED]> writes:
> Meanwhile, is this patch acceptable, which updates the _LIBC
> portions of the error module to resemble CVS glibc more closely, so
> that I have fewer spurious diffs to filter through?
Yes, and thanks for doing some of this (normally-thankless) task.
Bruno Haible clisp.org> writes:
> I object. We don't want to have a semantic difference between glibc 'error'
> and gnulib 'error'.
Point taken. So I will be opening up several glibc bugs over the next little
while, trying to see if we can get upstream to change first, starting with this:
http:
Eric Blake wrote:
> OK to check in? Note that it does affect the
> semantics of anyone using the error_print_progname callback - previously,
> error
> would not supply a space and now it does. But that is the only way I could
> make error_at_line consistent with GNU Coding Standards.
I objec
Paul Eggert CS.UCLA.EDU> writes:
> > Man, I wish there were an error() variant that took a va_list.
>
> That'd be a nice thing to add -- could you propose it?
...
> Initially I suppose this stuff should be written so that the new
> interface is exported only in gnulib mode.
>
I checked with gl
Eric Blake <[EMAIL PROTECTED]> writes:
> 2006-07-28 Eric Blake <[EMAIL PROTECTED]>
>
> * error.c (error_at_line): Match GNU Coding Standards.
The change looks good, but the ChangeLog entry is a bit terse; could
you please modify it to explain the bug it fixes.
> Man, I wish there were an
Ben Pfaff cs.stanford.edu> writes:
>
> Is it useful if it isn't pushed to glibc? It only updates code
> inside an #ifdef _LIBC block.
Actually, a different bug is present on non glibc platforms. When file_name is
NULL, error_at_file omits the required space in "program: message". My amended
Eric Blake <[EMAIL PROTECTED]> writes:
> On glibc platforms, error_at_line currently violates GNU coding standards
> when
> the output stream is in wide character mode. OK to apply? Does this need to
> be pushed to glibc?
Is it useful if it isn't pushed to glibc? It only updates code
inside
On glibc platforms, error_at_line currently violates GNU coding standards when
the output stream is in wide character mode. OK to apply? Does this need to
be pushed to glibc?
2006-07-28 Eric Blake <[EMAIL PROTECTED]>
* error.c (error_at_line): Fix typo in wide string.
Index: lib/er
10 matches
Mail list logo
