Re: rationale for closein

On Mon, Jun 18, 2012 at 08:17:25PM -0600, Eric Blake wrote: > On 06/18/2012 06:01 PM, Rich Felker wrote: > > > > > If the "closeout" approach works best for coreutils, that's the > > business of the coreutils' maintainers, not my business. However, as I > > discussed on the musl list, I think it'

Re: [musl] Re: musl bugs found through gnulib

On Mon, Jun 18, 2012 at 08:07:40PM -0600, Eric Blake wrote: > On 06/18/2012 06:11 PM, Rich Felker wrote: > > Some updates... > > > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > >> There is a recipe, in , > >> that explains how to

Re: stdioext on musl [was: gnulib portability issues]

On 06/18/2012 06:27 AM, John Spencer wrote: > I just couldn't withstand to express my disgust Please refrain from such rhetoric in the future. The bug-gnulib mailing list is for discussing ways to improve gnulib, and personal attacks get in the way of its purpose.

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 06:27 PM, John Spencer wrote: > easy: add a check for the invalid LD bit representations How does one do that, exactly? I thought the whole point of the proposed exercise was that code must be portable to any standard C implementation. So, where's the portable code to do what you're

Re: rationale for closein

On 06/18/2012 06:01 PM, Rich Felker wrote: > > If the "closeout" approach works best for coreutils, that's the > business of the coreutils' maintainers, not my business. However, as I > discussed on the musl list, I think it's bad design, and I would > highly recommend other projects not follow i

Re: isnanl, printf, and non-IEEE values

On 06/19/2012 04:00 AM, Eric Blake wrote: On 06/18/2012 07:27 PM, John Spencer wrote: It's nice to be able to print a floating point value retrieved from a file, even if the file got messed up somehow, ack. That argues that printf() should be robust to _everything_ you throw at it, even bit p

Re: [musl] Re: musl bugs found through gnulib

On 06/18/2012 06:11 PM, Rich Felker wrote: > Some updates... > > On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: >> There is a recipe, in , >> that explains how to use gnulib to check a libc against bugs. When I apply >> this to musl-0

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 07:27 PM, John Spencer wrote: >> It's nice to be >> able to print a floating point value retrieved from a file, >> even if the file got messed up somehow, > ack. That argues that printf() should be robust to _everything_ you throw at it, even bit patterns that are not produced by ar

Re: isnanl, printf, and non-IEEE values

On 06/19/2012 01:15 AM, Paul Eggert wrote: On 06/18/2012 05:07 AM, John Spencer wrote: it was already discussed that "GNU od" does, but it can be easily fixed there. I don't see how. easy: add a check for the invalid LD bit representations in ldtoastr() in gnulibs ftoastr.c. since it was writ

Re: rationale for closein

Rich Felker wrote about 'closeout': > ... Conceptually, you're > turning something that's a local variable ... into a global, and > thereby losing the _local_ > information of whether it was used in the first place, which has to be > recovered with the non-portable __fpending. Correct. We do this

Re: [musl] Re: musl bugs found through gnulib

Some updates... On Mon, Jun 18, 2012 at 12:49:44AM +0200, Bruno Haible wrote: > There is a recipe, in , > that explains how to use gnulib to check a libc against bugs. When I apply > this to musl-0.9.1, I get this list of problems: > > Replacements

Re: rationale for closein

On Tue, Jun 19, 2012 at 01:28:24AM +0200, Bruno Haible wrote: > Rich Felker wrote in > : > > I've already discussed on this list why using an atexit function for > > closing stdin or stdout is the heart of the problem and the source of > > all the co

Re: MacOS X -> Mac OS X

Hi Max, > I noticed that gnulib (almost) consistently misspells "Mac OS X" as > "MacOS X". Indeed, you're right. I've been consistently writing "MacOS X", whereas now I see that 95% of the rest of the world writes "Mac OS X", including Wikipedia. Google hits for "MacOS X"36e6 Google hits for

rationale for closein

Rich Felker wrote in : > I've already discussed on this list why using an atexit function for > closing stdin or stdout is the heart of the problem and the source of > all the complexity. If the main program just closed the stream at the > natural po

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 05:07 AM, John Spencer wrote: > it was already discussed that "GNU od" does, > but it can be easily fixed there. I don't see how. And even if it could be, why not just leave things as they are? It's nice to be able to print a floating point value retrieved from a file, even if the

Re: MacOS X -> Mac OS X

On 06/18/2012 07:59 AM, Max Horn wrote: > Hi there, > I noticed that gnulib (almost) consistently misspells "Mac OS X" as "MacOS X" But "Mac OS X" is incorrect too. The operating system's name is now just "OS X", or (if the version matters) "OS X Mountain Lion", as of February. See

Re: isnanl, printf, and non-IEEE values

Rich Felker writes: > On Mon, Jun 18, 2012 at 10:21:34AM -0700, Ben Pfaff wrote: >> Bruno Haible writes: >> >> > In theory you would be right that data should be validated at the >> > boundaries >> > of the program, that is, when they are read from outside sources. But no >> > program I know o

Re: isnanl, printf, and non-IEEE values

On Mon, Jun 18, 2012 at 10:21:34AM -0700, Ben Pfaff wrote: > Bruno Haible writes: > > > In theory you would be right that data should be validated at the boundaries > > of the program, that is, when they are read from outside sources. But no > > program I know of does this for unconstrained float

Re: isnanl, printf, and non-IEEE values

Bruno Haible writes: > In theory you would be right that data should be validated at the boundaries > of the program, that is, when they are read from outside sources. But no > program I know of does this for unconstrained floating-point numbers. That's an interesting point. GNU PSPP reads unco

Re: new module: relpath

> Date: Mon, 18 Jun 2012 09:39:26 -0600 > From: Eric Blake > CC: Akim Demaille , bug-gnulib@gnu.org > > >> + while (*path1 && *path2) > >> +{ > >> + if (*path1 != *path2) > > > > This comparison should be case-insensitive for MS-Windows. > > Shouldn't normalization already guarantee c

Re: new module: relpath

On 06/18/2012 09:30 AM, Eli Zaretskii wrote: >> At least to experiment on the concept, and on a suggestion from >> Eric Blake weeks ago, I stole bits of the coreutils, and made them >> a gnulib module. > > Perhaps the comments below, mainly related to portability to > MS-Windows (but not only tha

Re: new module: relpath

> From: Akim Demaille > Date: Thu, 14 Jun 2012 18:02:35 +0200 > > In Bison, I consider computing relative paths between files > (one concrete use is when the user creates the parser implementation > file in --output=sub1/sub2/parser.c and the header file in > --defines=sub3/sub4/parser.h, in whic

MacOS X -> Mac OS X

Hi there, I noticed that gnulib (almost) consistently misspells "Mac OS X" as "MacOS X". Of course that's not really a problem, but since apparently some effort went into correctly spelling the names of other OSes (e.g. FreeBSD, BeOS, ...) I was wondering whether a patch that resolves this would

Re: GNU sed version 4.2.1: on OS X, C locale gets aliased to UTF-8

Hi again, it would be really, really nice to get this issue resolved, one way or another :-). As mentioned, in the current state of things, GNU sed (via gnulib) does not work correctly on Mac OS X when e.g. LANG=C is set, leading to real-world errors for users when using e.g. git while GNU sed

LGPL-ing gnulib - was: new module: relpath

On 06/18/12 05:52, Eric Blake wrote: + realtarget = canonicalize_filename_mode (target, CAN_MISSING); Indeed, for this to be LGPL, we would have to change canonicalize_filename_mode() to have a looser license, and I'm not sure it is a wise idea to attempt that. Indeed, perhaps just blanket l

Re: isnanl, printf, and non-IEEE values

On 06/18/2012 03:06 PM, Bruno Haible wrote: John Spencer wrote: its not the job of the libc to make broken code happy. i dont think its a good idea to make thousands of correct programs slower, just that GNU guys dont have to fix one program. Following your argumentation, we don't need - W^

Re: stdioext on musl [was: gnulib portability issues]

On Sun, 17 Jun 2012 16:59:45 -0700, Bruno Haible wrote Rich Felker wrote > If gnulib is willing to _detect_ working functions rather than trying to detect musl [...] > We often, but not always, use an autoconf test that verifies that a > function works. Why not always? Because such a test i

Re: isnanl, printf, and non-IEEE values

John Spencer wrote: > its not the job of the libc to make broken code happy. > > i dont think its a good idea to make thousands of correct programs slower, > just that GNU guys dont have to fix one program. Following your argumentation, we don't need - W^X protection in the x86 hardware, - ad

Re: new module: relpath

On 06/18/2012 05:38 AM, Akim Demaille wrote: >>> >> +License: >>> >> +GPLv3+ >> > >> > This module may produce error messages and be under GPL. Then the module >> > is not usable in shared libraries. If you want a module that is more widely >> > usable, consider an interface that returns error co

Re: new module: relpath

On 06/18/2012 04:02 AM, Akim Demaille wrote: >> We really shouldn't be using malloc(PATH_MAX); there are platforms like >> Hurd where it is undefined or extremely large (coreutils caps things to >> avoid this issue), and you are wasting memory if it is even possible to >> allocate this much. Furt

Re: isnanl, printf, and non-IEEE values

onSun, 17 Jun 2012 16:00:13 -0700 Paul Eggert wrote On 06/17/2012 03:41 PM, Rich Felker wrote: No program I know of reads long double directly from binary files. 'od -tfL' does. it was already discussed that "GNU od" does, but it can be easily fixed there. its not the job of the libc to

Re: new module: relpath

Hi Bruno, I will address these issues step by step, time permitting. Again, help is most welcome. Le 16 juin 2012 à 17:25, Bruno Haible a écrit : >> +++ b/modules/relpath > >> +Depends-on: >> +canonicalize >> +dirname >> +error >> +pathmax >> +stdbool >> +xalloc >> +... >> +License: >> +GPLv3+

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

On Mon, Jun 18, 2012 at 12:01:01PM +0100, Richard W.M. Jones wrote: > On Mon, Jun 18, 2012 at 11:44:08AM +0100, Richard W.M. Jones wrote: > > On Mon, Jun 18, 2012 at 12:33:36PM +0200, Jim Meyering wrote: > > > [libtool-kill-dependency_libs.sh] > > > That looks promising. > > > Can you easily refrai

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

On Mon, Jun 18, 2012 at 11:44:08AM +0100, Richard W.M. Jones wrote: > On Mon, Jun 18, 2012 at 12:33:36PM +0200, Jim Meyering wrote: > > [libtool-kill-dependency_libs.sh] > > That looks promising. > > Can you easily refrain from using that when building gnulib's own tests? > > I've removed that now

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

On Mon, Jun 18, 2012 at 12:33:36PM +0200, Jim Meyering wrote: > [libtool-kill-dependency_libs.sh] > That looks promising. > Can you easily refrain from using that when building gnulib's own tests? I've removed that now. Still happens. However I think this could be a bug in libtool (from RHEL 5).

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

Richard W.M. Jones wrote: > On Mon, Jun 18, 2012 at 12:09:41PM +0200, Jim Meyering wrote: >> That suggests that it linked. >> >> In what context did you see the link failure? >> While running tests for some other package? > > Yes, this is the attempt to get libguestfs working again on RHEL 5. > >

Re: Libvirt / GNULIB failures using Mingw64 toolchain

On Sun, Jun 17, 2012 at 04:28:02PM +0200, Bruno Haible wrote: > Hello Daniel, > > > CC fstat.lo > > ../../../gnulib/lib/fstat.c:27:0: warning: "stat" redefined [enabled by > > default] > > In file included from ./sys/stat.h:32:0, > > from ../../../gnulib/lib/fstat.c:25: > >

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

On Mon, Jun 18, 2012 at 12:09:41PM +0200, Jim Meyering wrote: > That suggests that it linked. > > In what context did you see the link failure? > While running tests for some other package? Yes, this is the attempt to get libguestfs working again on RHEL 5. It could also be because of 'libtool-k

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

Richard W.M. Jones wrote: > On Mon, Jun 18, 2012 at 11:53:01AM +0200, Jim Meyering wrote: >> Richard W.M. Jones wrote: >> > With gnulib from around May 25th, I get this error when compiling >> > on RHEL 5. >> > >> > bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC >> > --mode=link

Re: new module: relpath

Le 14 juin 2012 à 18:55, Eric Blake a écrit : >> +/* Return FROM represented as relative to the dir of TARGET. >> + The result is malloced. */ >> + >> +char * >> +convert_abs_rel (const char *from, const char *target) >> +{ >> + char *realtarget = canonicalize_filename_mode (target, CAN_MISSI

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

On Mon, Jun 18, 2012 at 11:53:01AM +0200, Jim Meyering wrote: > Richard W.M. Jones wrote: > > With gnulib from around May 25th, I get this error when compiling > > on RHEL 5. > > > > bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC > > --mode=link gcc -g -O2 -o test-futimens test-f

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

Richard W.M. Jones wrote: > With gnulib from around May 25th, I get this error when compiling > on RHEL 5. > > bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC > --mode=link gcc -g -O2 -o test-futimens test-futimens.o libtests.a > ../../gnulib/lib/libgnu.la libtests.a -lrt > gcc -g

Re: gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

On Mon, Jun 18, 2012 at 10:26:57AM +0100, Richard W.M. Jones wrote: > > With gnulib from around May 25th, I get this error when compiling > on RHEL 5. > > bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC --mode=link > gcc -g -O2 -o test-futimens test-futimens.o libtests.a >

gnulib/tests/utimecmp.c:183: undefined reference to `hash_insert'

With gnulib from around May 25th, I get this error when compiling on RHEL 5. bash ../../libtool-kill-dependency_libs.sh ../../libtool --tag=CC --mode=link gcc -g -O2 -o test-futimens test-futimens.o libtests.a ../../gnulib/lib/libgnu.la libtests.a -lrt gcc -g -O2 -o test-futimens test-fut