> GNU tar 1.19 doesn't build on Solaris 8, because strerror.c uses
> CHAR_BIT without defining it. The problem occurs on any hosts that
> has strerror but where strerror(-2) doesn't return a useful string.
I'm committing this followup:
From: Eric Blake <[EMAIL PROTECTED]>
Date: Thu, 11 Oct 2007
> > + static char const fmt[] = "Unknown error (%d)";
>
> The only improvement I see is to change the string to something like
> "errno=%d", since it won't be translated to a native language. That's
> good enough for a substitute function.
That string was the same as what was used in the missi
> > I am very much in favor of a gnulib
> > implementation of strerror that works harder to provide non-NULL
> results.
>
> Sounds like we need to update the gnulib replacement for strerror to
> accomodate broken platforms like Interix.
How about the following?
From: Eric Blake <[EMAIL PROTECT
> The Austin group debated making the next version of POSIX required to
> always return a non-NULL result for strerror (although for out-of-range
> errors, there was no guarantee that the string had to be unique, as in
> printing what the out-of-range value was). However, I think that proposal
>
> In fact, I've just removed the underscores in __fpending.[ch]:
>
> 2007-09-08 Jim Meyering <[EMAIL PROTECTED]>
>
> Rename __fpending.c -> fpending.c and __fpending.h -> fpending.h
> * lib/fpending.h: Rename from __fpending.h.
And in the process, broke builds for platforms that l
> What do you use for recursive grepping? Is "grep -r --exclude=dir=.git"
> working fine?
'git grep' works nicely - it recursively greps all files tracked
under version control, while omitting generated files.
--
Eric Blake
--
View this message in context:
http://www.nabble.com/git-and-grep-
> The patch to m4/lock.m4 has this problem, and also another one: lock.m4 is
> used as part of the gettext infrastructure, which requires only autoconf
> >= 2.54 and should not include extensions.m4. - Can you change m4/lock.m4
> to use AC_USE_SYSTEM_EXTENSIONS only in autoconf version >= 2.62, an
> > Don't consume too much input when stdin is seekable.
> > * lib/yesno.c (yesno): Flush seekable stdin.
> > * modules/yesno (Depends-on): Add fflush.
>
> Won't this patch result in lots of unnecessary system calls for a
> program that reads a lot of 'y's and 'n'n from a file?
Ouch
> The yesno module has a problem on platforms where exit()
> does not implicitly flush seekable input streams
The yesno module also has a potential POSIX-compliance problem
on all platforms. Inside rpmatch, the code uses _("^[yY]") to
get the locale-specific regex to use as the yesexpr. However
The yesno module has a problem on platforms where exit()
does not implicitly flush seekable input streams (this behavior
of exit() is contrary to POSIX, but glibc behaves this way,
and Ulrich was unwilling to fix the glibc bug [1]). Basically,
because the yesno module consumes input from stdin, i
> Thanks for your patch. But how does it solve the original problem? Only
> because it enables include_next for compilers that support it, and Sun
> Studio cc happens to be one of these compilers, right?
I think, (but don't know for sure as I'm not on a Sun), that the problem
is that Sun's used
> > I'm surprised to hear you arguing that it is desirable for glibc's printf
> > implementation to segfault for a long-double with an unusual bit
> pattern.
>
> In which way is this different from printf("%s", (char*)1)?
I see a huge difference between passing an invalid pointer (your
printf("%
> Paul Eggert wrote:
> > But the function names use leading __ in both Solaris and glibc, and I
> > expect that if they are ever standardized they'll be standardized with
> > the leading __.
>
> I sincerely hope no standardization group would do such a mistake:
As do I. If it is worth standardi
> Even on Linux, the fflush man page doesn't mention input streams:
>
>http://www.die.net/doc/linux/man/man3/fflush.3.html
>
> So it seems that using fflush(stdin) is probably the wrong thing
> to do altogether for a portable application.
On the contrary, it makes it sound like we write a g
> >
> > Yes, just add gnulib-cache.m4 to EXTRA_DIST in your top-level
> Makefile.am.
> > See recent coreutils or m4 package releases for examples.
> >
>
> I noticed, after an update that this file is also added in the gnulib
> directory
>
> gnulib-common.m4
>
> but it is not included in the
> > I was assuming that invoking AC_SYS_LARGEFILE is the programmer's
> > responsibility, because AC_SYS_LARGEFILE is a global switch.
>
> Yes, that was my assumption too. However, as you mentioned, any
> portable program that accesses files should use AC_SYS_LARGEFILE these
> days.
Should we j
> I've checked it in:
>
> 2006-10-23 Jim Meyering <[EMAIL PROTECTED]>
>
> * lib/getaddrinfo.c (getnameinfo): Use new lightweight uinttostr,
> in place of snprintf.
You missed a piece:
gcc -Wall -DHAVE_CONFIG_H -I. -I.. -I../../gllib -g -O2 -MT
getaddrinfo.o -MD -MP -MF .deps/
> > It didn't make it into automake 1.10, but Alexandre approved it for the
> > next release:
> > http://www.nabble.com/forum/ViewPost.jtp?post=6824228&framed=y. OK to
> > apply this to gnulib for projects living on the bleeding edge?
>
> Sure, please go ahead. But please observe the order in t
> > It shouldn't be too hard to modify the example to find out for sure...
>
> Could you? I need an example to file a FreeBSD problem report.
>
> Thanks!
Cygwin includes this version of BSD getopt:
/* $OpenBSD: getopt_long.c,v 1.16 2004/02/04 18:17:25 millert Exp $
*/
/* $NetB
> = > Finally, does m4 actually use/document the short-options usage, that's
> = > affected by the POSIX vs. GNU differences in getopt()?
> =
> = Yes, the info documentation for m4's -d discusses the ramifications of
> its
> = argument being optional (and if that text is not clear enough for you,
>
> (*) I added to gnulib a file users.txt listing the uses of gnulib that
> I found so far.
>
Nice list. I sorted it, and added tar.
--
Eric Blake
--
View this message in context:
http://www.nabble.com/Re%3A-sync-from-gnulib-to-coreutils-tf2086545.html#a5765268
Sent from the Gnulib
> Confirmed. Thanks, Albert! I wasn't aware that this was the same bug
> that we work around in so many other places.
>
> I'm adding the fix below to gnulib. No need any more for -I/usr/include
> or option -nodtk.
Why don't we instead add a new module, wchar, which provides a replacement
using
> Eric Blake asked:
> > Is it worth adding a system module to gnulib that detects
> implementations with
> > this bug, and provides rpl_system to work around it?
>
> The specification of system() in ISO C 99 does not specify
> 1) which is the command processor,
> and in particular which a
23 matches
Mail list logo
