Le 16 juin 2012 à 17:25, Bruno Haible a écrit :
Hi Akim,
Hi Bruno,
Thanks for the detailed comments.
About the module name 'relpath': The GNU standards, section GNU Manuals,
say
Please do not use the term pathname that is used in Unix
documentation; use file name (two words) instead.
Hi Pádraig!
Le 16 juin 2012 à 18:15, Pádraig Brady a écrit :
On 06/16/2012 04:25 PM, Bruno Haible wrote:
I agree that
1. this is general-purpose functionality that has its place in gnulib,
2. when you start to copy code from coreutils to bison, it's time to
move it to gnulib, to
Hi Pádraig,
concat-filename
filename
filenamecat
It would be good to choose a module name in this spirit.
I suppose relname would be most appropriate given that argument,
though I think in this case it's slightly better to keep the relpath name
so as to align with similar
Hi Paul,
Daniel P. Berrange wrote:
While on x86_64-w64-mingw32 only I see:
In file included from ../../../gnulib/lib/regex.c:69:0:
../../../gnulib/lib/regcomp.c: In function 'parse_dup_op':
../../../gnulib/lib/regcomp.c:2624:39: warning: cast to pointer from integer
of different size
On 06/17/2012 03:02 PM, Jim Meyering wrote:
Akim Demaille wrote:
Le 16 juin 2012 à 17:25, Bruno Haible a écrit :
Hi Akim,
Hi Bruno,
Thanks for the detailed comments.
...
+Depends-on:
+canonicalize
+dirname
+error
+pathmax
+stdbool
+xalloc
+...
+License:
+GPLv3+
This module may
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:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/sys/stat.h:258:0: note: this
is the
On 06/17/2012 10:54 AM, Bruno Haible wrote:
Hi Pádraig,
concat-filename
filename
filenamecat
It would be good to choose a module name in this spirit.
I suppose relname would be most appropriate given that argument,
though I think in this case it's slightly better to keep the
Hi Jim, Reuben,
Since this file is trivial, would it be possible to give it an
all-permissive license? Someone has just (helpfully!) pointed out that
it shouldn't be in a BSD-licensed project I maintain, where it gets
pulled in by bootstrap.
If dummy's license is causing trouble, how
Paul Eggert wrote:
On 06/12/2012 04:21 AM, Paolo Bonzini wrote:
perhaps we can follow the suggestion and
replace if (freadahead (f)) with if (freading(f) !feof(f)) in
closein.c.
Yes, thanks, I like this idea the best of those suggested so far.
Here's a proposed patch to gnulib.
Pádraig Brady wrote:
Since there are lots of appending of strings here,
the approach taken in coreutils so far was
to append in a large buffer allocated up front,
or just to write to stdout.
I guess something in between is more appropriate for a lib.
I.E. efficiently append to a string on
On 06/17/2012 07:00 AM, Bruno Haible wrote:
For portability the cast to 'long' should better be replaced with a cast
to 'intptr_t'.
Thanks, I did that, except I used uintptr_t since the value in
question is a size_t value.
regex: avoid warning when pointers are not long
* lib/regcomp.c
FYI, since I let the default GPG-key-deriving code get my key from
the just-created tag (the default), I noticed that it was broken.
This fix matters only at release time, and if you don't set
gpg_key_ID in cfg.mk:
From 5eae670f051c94b73d7dd6aae2d4a814ca691f9e Mon Sep 17 00:00:00 2001
From: Jim
Rich Felker wrote:
1. freadahead is inherently non-portable and has no working portable
fallback version. At some point in the discussions, it was suggested
that this function should not be pulled in except on old broken
systems where stdio doesn't work and needs replacement functions.
Hi Paul,
They're purposefully opaque so that they can be changed if an
alternate implementation proves better.
Dragonfly BSD attacked this problem by supplying a
function __sreadahead that returns the value in question.
Perhaps musl could do something similar? That would fix
the
Eric Blake wrote:
Furthermore, I'm considering writing a proposal for the next version of
POSIX to standardize several of the stdio functions currently provided
by gnulib, along with rationale why they are useful and how they can be
used to speed up programs. The fact that gnulib is an
Rich Felker wrote:
2. Several tests for isnanl and printf long double support are
invalid. They are generating invalid LD80 representations that cannot
occur as values (pseudo-denormal, for example) and testing that
isnanl and printf treat these as NAN. Per the C standard, there is no
Isaac Dunham wrote:
The test as it stands is error out on unsupported platforms unless
user specifies to use slow method.
My proposal is On unsupported platforms, use the slow method instead
of erroring out.
If we did this, nobody would report to bug-gnulib (or to the libc maintainer)
the
Rich Felker wrote:
considering printf broken, and replacing printf
because of this, is a big issue. Replacing printf is non-trivial
There is also another test that causes musl's printf to be overridden:
checking whether printf supports the 'ls' directive... no
The test program exited with
On Sun, Jun 17, 2012 at 10:56:48PM +0200, Bruno Haible wrote:
Rich Felker wrote:
1. freadahead is inherently non-portable and has no working portable
fallback version. At some point in the discussions, it was suggested
that this function should not be pulled in except on old broken
On Sun, Jun 17, 2012 at 11:57:05PM +0200, Bruno Haible wrote:
Rich Felker wrote:
considering printf broken, and replacing printf
because of this, is a big issue. Replacing printf is non-trivial
There is also another test that causes musl's printf to be overridden:
checking whether
On 06/17/2012 02:56 PM, Rich Felker wrote:
1) Currently, gnulib has to go to a great length to detect musl.
It uses the presence of __stdio_read and __stdio_write as an indicator;
That's not valid. These are internal functions that could be renamed
or disappear (e.g. be changed to
On Sun, Jun 17, 2012 at 11:33:45PM +0200, Bruno Haible wrote:
The other justification for handling these representations was brought up
by Jim in the long thread that surrounded this glibc bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=4586
[CCing the musl list]
Isaac Dunham wrote in
http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html:
musl is designed for standards conformance,
There is a recipe, in http://sourceware.org/glibc/wiki/Testing/Gnulib,
that explains how to use gnulib to check a libc against bugs. When I
Rich Felker wrote:
checking whether printf supports the 'ls' directive... no
Yep, I caught this one a while back. It's fixed in git.
Good to hear that.
Bruno
On Sun, Jun 17, 2012 at 03:44:16PM -0700, Paul Eggert wrote:
will configure even find them?
Yes, it can be made to find them, as part of gnulib.
I mean will it find them without needing a special macro like
__MUSL__?
This is a pragmatic approach that works well in practice. Bruno has
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. I'm sure there are others. It's pretty
common to save binary data into files and restore it later.
On 06/17/2012 03:53 PM, Rich Felker wrote:
By better interfaces do you mean the
4 already-mentioned stdio extension functions, or something else?
Yes, I mean the functions that Bruno mentioned.
I mean will it find them without needing a special macro like
__MUSL__?
Having a symbol like
Rich Felker wrote:
So isnanl is expected to be slower in every program that's using it
for legitimate arithmetic purposes
Yes. But it will not be slower by much. The CPUs have an instruction for
'fpclassify'; you just need to pass the right bitmask to that instruction.
Are you sure
On Sun, Jun 17, 2012 at 04:10:52PM -0700, Paul Eggert wrote:
On 06/17/2012 03:53 PM, Rich Felker wrote:
By better interfaces do you mean the
4 already-mentioned stdio extension functions, or something else?
Yes, I mean the functions that Bruno mentioned.
I mean will it find them
Rich Felker wrote:
2) Provide 4 primitive functions.
This is less offensive at least, but will configure even find them?
Eric Blake offered to make it work that way, but you seem to want to
test against macros that identify the implementation...? If gnulib is
willing to _detect_ working
[CCing the musl list]
Isaac Dunham wrote in
http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html:
musl is designed for standards conformance,
There is a recipe, in http://sourceware.org/glibc/wiki/Testing/Gnulib,
that explains how to use gnulib to check a libc against bugs.
Be
[CCing the musl list]
Isaac Dunham wrote in
http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00101.html:
musl is designed for standards conformance,
There is a recipe, in http://sourceware.org/glibc/wiki/Testing/Gnulib,
that explains how to use gnulib to check a libc against bugs.
Be
On Mon, Jun 18, 2012 at 02:01:28AM +0200, Bruno Haible wrote:
Rich Felker wrote:
2) Provide 4 primitive functions.
This is less offensive at least, but will configure even find them?
Eric Blake offered to make it work that way, but you seem to want to
test against macros that identify
Rich,
Then Bruno came back to us with this monstrosity of a patch that
insists, for no good reason, on trying to detect musl specifically,
thereby increasing the amount of broken special-cased non-portable
code in gnulib rather than modernizing it.
...
What is my business is that Bruno
Rich Felker wrote:
This is not hypothetical at all. The __freading, __fwriting functions
exist in various libcs (glibc, Solaris, uClibc, musl). But only in musl
the value is different in some particular case. Therefore I ask you to
Would you mind telling me how it's different and how
On Mon, Jun 18, 2012 at 02:59:56AM +0200, Bruno Haible wrote:
For 2), the issue is that for a stream opened in write-only mode,
immediately after the fopen() call, gnulib expects fwriting(fp) to be
true:
Thanks. I committed a change whereby __freading now returns 1 whenever
the stream is
36 matches
Mail list logo
