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 is
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.
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 ebl...@redhat.com writes:
Wrong. Pretty much every libc out there lets you ungetc() more than one
byte.
Does that include glibc? Then there is a bug in the manual,
which says:
The GNU C library only supports one character of
pushbackâin other words, it does not
On 06/12/2012 01:04 AM, Ben Pfaff wrote:
Eric Blake ebl...@redhat.com writes:
Wrong. Pretty much every libc out there lets you ungetc() more than one
byte.
Does that include glibc? Then there is a bug in the manual,
which says:
The GNU C library only supports one character of
On 06/09/2012 06:39 PM, Rich Felker wrote:
Hi,
Reuben suggested I contact upstream since we've been discussing on the
musl mailing list (m...@lists.openwall.com, archive at
http://www.openwall.com/lists/musl/) some of the difficulties that
have arisen out of gnulib and programs using it
On Tue, Jun 12, 2012 at 06:21:24AM -0600, Eric Blake 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
On 06/12/2012 07:46 AM, Rich Felker wrote:
Actually, there IS a need to handle these representations. The 'od'
program in coreutils is an example of where POSIX requires us to handle
ANY bit pattern as given in an arbitrary input file as ANY other type of
number, including long doubles. And
On Tue, Jun 12, 2012 at 06:12:39AM -0600, Eric Blake wrote:
And this simple program proves that most libc know how to push back more
than one byte, whether or not they differ from the original contents,
and especially in the common case where the byte still fits in the
buffer. It's the corner
On 06/12/2012 08:03 AM, Rich Felker wrote:
On Tue, Jun 12, 2012 at 06:12:39AM -0600, Eric Blake wrote:
And this simple program proves that most libc know how to push back more
than one byte, whether or not they differ from the original contents,
and especially in the common case where the byte
On 06/12/2012 08:20 AM, Rich Felker wrote:
To me, the only difference is the pain of replacing them. You cannot
have these bit patterns in an LD80 without your program having invoked
undefined behavior (accessing an object as a type other than its
effective type or one of the allowed
On Tue, Jun 12, 2012 at 09:07:05AM -0600, Eric Blake wrote:
On 06/12/2012 08:20 AM, Rich Felker wrote:
To me, the only difference is the pain of replacing them. You cannot
have these bit patterns in an LD80 without your program having invoked
undefined behavior (accessing an object as a
On 06/10/2012 07:47 PM, Rich Felker wrote:
If you think it matters, __freading could be used instead.
That doesn't sound right, since Solaris/glibc __freading returns 1
on read-only streams, whereas we want to know whether
the stream has a nonempty input buffer; this is not
the same thing.
On 06/09/2012 10:25 PM, Rich Felker wrote:
While fixing the underlying freadahead function would be nice, it
might be better to make sense of WHY it's needed/wanted, if it's even
actually useful, and how to avoid the need for it in the first place.
GNU M4 (at least the master branch, although
On 06/10/2012 06:43 AM, Rich Felker wrote:
Come to think of it, a variant might even work for seekable files.
Use dup2 to move the file descriptor somewhere else. Close the
fd. Keep reading until error, and count the bytes read. Then
ungetc all the bytes that you read, in reverse order,
On Mon, Jun 11, 2012 at 06:10:02AM -0600, Eric Blake wrote:
On 06/09/2012 10:25 PM, Rich Felker wrote:
While fixing the underlying freadahead function would be nice, it
might be better to make sense of WHY it's needed/wanted, if it's even
actually useful, and how to avoid the need for it
On Mon, Jun 11, 2012 at 06:13:03AM -0600, Eric Blake wrote:
On 06/10/2012 06:43 AM, Rich Felker wrote:
Come to think of it, a variant might even work for seekable files.
Use dup2 to move the file descriptor somewhere else. Close the
fd. Keep reading until error, and count the bytes
On 06/11/2012 06:54 AM, Rich Felker wrote:
GNU M4 (at least the master branch, although it has not yet been
released as m4 2.0) _wants_ to use freadahead, because it provides at
least a 10% speedup in operation. It _really is_ more efficient to peek
at the current buffer in one function call
On Mon, Jun 11, 2012 at 07:14:56AM -0600, Eric Blake wrote:
On 06/11/2012 06:54 AM, Rich Felker wrote:
GNU M4 (at least the master branch, although it has not yet been
released as m4 2.0) _wants_ to use freadahead, because it provides at
least a 10% speedup in operation. It _really is_
On 06/11/2012 07:19 AM, Rich Felker wrote:
But if your goal is to read up until the next character in a
particular set of special characters, why not fscanf(f, %100[^xyz],
...) with 100 replaced by your buffer size and xyz replaced by the
specials?
Because fscanf() is broken by design. M4
On Sat, Jun 09, 2012 at 10:01:38PM -0700, Paul Eggert wrote:
On 06/09/2012 09:25 PM, Rich Felker wrote:
For seekable input, comparing ftello(f) and the underlying fd offset
from lseek(fileno(f),0,SEEK_CUR) would work, but that also will fail
for non-seekable input.
Thanks, that's better
On Sat, Jun 09, 2012 at 10:01:38PM -0700, Paul Eggert wrote:
it might be better to make sense of WHY it's needed/wanted
Yes, quite true, but that information wasn't communicated to the
gnulib mailing list.
For GNU m4, it seems freadahead is not used directly. Instead, it's
pulled in by
On 06/10/2012 06:10 AM, Rich Felker wrote:
As such, the first fix I would recommend is simply removing the check
for freadahead(stdin)0 from closein.c
But that will hurt performance on GNU/Linux and most other
POSIXish hosts, as it will cause them to issue lseek
system calls and whatnot that
On 06/10/2012 05:43 AM, Rich Felker wrote:
If the latter is acceptable though, the stdio_ext.h function
__freading might suffice as an implementation.
On musl doesn't __freading actually return a count?
Perhaps we could just use that.
On Sun, Jun 10, 2012 at 07:02:32PM -0700, Paul Eggert wrote:
On 06/10/2012 06:10 AM, Rich Felker wrote:
As such, the first fix I would recommend is simply removing the check
for freadahead(stdin)0 from closein.c
But that will hurt performance on GNU/Linux and most other
POSIXish hosts, as
Hi,
Reuben suggested I contact upstream since we've been discussing on the
musl mailing list (m...@lists.openwall.com, archive at
http://www.openwall.com/lists/musl/) some of the difficulties that
have arisen out of gnulib and programs using it when building on musl
Patches for any of these problems would be welcome.
As freadahead seems to be most pressing, it sounds
like that's the best one to work on first.
1. freadahead is inherently non-portable
That sounds like a challenge! How about using
the following patch? Does it work for you, if
you define
On Sat, Jun 09, 2012 at 09:06:21PM -0700, Paul Eggert wrote:
Patches for any of these problems would be welcome.
As freadahead seems to be most pressing, it sounds
like that's the best one to work on first.
1. freadahead is inherently non-portable
That sounds like a challenge! How about
On 06/09/2012 09:25 PM, Rich Felker wrote:
For seekable input, comparing ftello(f) and the underlying fd offset
from lseek(fileno(f),0,SEEK_CUR) would work, but that also will fail
for non-seekable input.
Thanks, that's better than what I wrote. Perhaps you could write up
a patch along those
29 matches
Mail list logo
