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.
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
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
> th
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
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 excep
On Tue, Jun 12, 2012 at 08:02:58AM -0600, Eric Blake wrote:
> > If you were just using gnulib to replace isnanl in od, it wouldn't be
> > such an issue. But considering printf broken, and replacing printf
> > because of this, is a big issue. Replacing printf is non-trivial, and
> > might not even w
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 th
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 cor
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 double
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
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 i
On 06/12/2012 01:04 AM, Ben Pfaff wrote:
> Eric Blake 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
>
Eric Blake 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 work to call unget
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.
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 _re
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 functi
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
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
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 or
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, althou
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.
> Th
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 h
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 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 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 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
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 thos
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! Ho
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 SLO
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
(http://www.etalabs.net/musl/).
30 matches
Mail list logo
