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 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.
>From 43f704124bc3a96dc1
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
Il 12/06/2012 14:14, Eric Blake ha scritto:
>> > While I agree with this, perhaps we can follow the suggestion and
>> > replace "if (freadahead (f))" with "if (freading(f) && !feof(f))" in
>> > closein.c.
> freading() is just as much an extension as freadahead(), but it might be
> an easier extensi
Hi!
Le 7 juin 2012 à 18:10, Jim Meyering a écrit :
> Looks fine. One suggested addition:
>
>> @@ -67,7 +68,8 @@ These options must be specified:
>>
>> The following are optional:
>>
>> - --news=NEWS_FILE
>> + --news=NEWS_FILE accumulates
>
> Telling how to use it, good!
> How
Le 11 juin 2012 à 14:11, Jim Meyering a écrit :
> Hi Akim,
>
> You're welcome to use pwd.
> set -e is in effect, so pwd failure will be caught, and changing
> the working directory in a script like this is not a problem.
Hi Jim!
commit b630d56579abda426606c94747748982f30e4a6c
Author: Akim Dema
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 05:21 AM, Paolo Bonzini wrote:
> Il 08/06/2012 12:19, Pedro Alves ha scritto:
Have you any plans to address these problems? In particular, it does
seem odd to place a burden on libc authors of porting gnulib to it,
rather than just not supporting those functions which r
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
>
Please don't forget fseterr, the other rude #erroring spot which fails
even though there is deactivated portable fallback code.
Subject: [PATCH] 6 syscalls is still better than a failed build
---
lib/fseterr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/fseter
Il 12/06/2012 03:22, Isaac Dunham ha scritto:
>> > Performance, surely. But if there's
>> > consensus that performance does not matter that
>> > much with musl, perhaps we should default to the
>> > slow version with musl.
> The test as it stands is "error out on unsupported platforms unless
> use
Il 08/06/2012 12:19, Pedro Alves ha scritto:
>> > Have you any plans to address these problems? In particular, it does
>> > seem odd to place a burden on libc authors of porting gnulib to it,
>> > rather than just not supporting those functions which require
>> > non-standard APIs on such libc's.
>
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
18 matches
Mail list logo
