Eric Blake wrote:
> the real bug was that freadseek was incrementing the in-memory pointer
> beyond the bounds of the ungetc buffer).
True. But the use of freadahead was not entirely wrong. Because when the
stream is in ungetc state, what you don't want is:
- read the ungetc buffer (1 byte) with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 3/29/2008 5:59 AM:
| At this point, waiting for a resolution by the Austin Group (Geoff Clare's
| mail is an important opinion, but not yet a decision), I prefer to not
change
| the code, but just disable the test.
Thanks
libc and cygwin; but lib/fflush.c takes this into account.
--- 33,43
/* POSIX requires fflush-fseek to set file offset of fd. */
if (fflush (f) != 0 || fseek (f, 0, SEEK_CUR) != 0)
return 4;
! if (lseek (fd, 0, SEEK_CUR) != 5)
! return 5;
!/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 3/28/2008 11:14 PM:
| There is no need to penalize Linux with an fflush wrapper if the only
| issue with it is behavior during condition 2, since no sane code should be
| trying to use condition 2. But we should probably op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 3/9/2008 3:13 PM:
|
| Let's see what Austin decides. gnulib now implements options 1b+2b (in the
| terms of my earlier mail); I'm ready to change it, whatever gets decided.
Cygwin 1.5.25-11 implements 1a+2a, and does not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Geoff Clare on 3/26/2008 11:05 AM:
| [I've been meaning to get round to looking into this one for a
| while; sorry it took so long.]
Thanks for a reply. I'd been meaning to ping on this, but your reply beat me.
|
| Eric Blake <[EMAIL P
Eric Blake wrote:
> > On HP-UX 11:
> > When reading from the pipe:
> > c = '#'
> > c = 'i'
> > ungetc result = '@'
> > c =
> > c =
>
> Bug - C99 requires that ALL streams have at least one byte of ungetc space,
> with no limitation on what can go in that buffer. You only invoke
> unspecified
Eric Blake wrote:
> I'm starting to waffle on what POSIX
> requires. Maybe it's worth asking the Austin Group after all?
Yes, thanks for asking the Austin Group.
> Swapped comments.
> ...
> Cygwin listed twice. But be aware that there was a change in cygwin behavior
> from 1.5.25-10 to 1.5.25
Eric Blake wrote:
> But my questions about fflush on seekable input streams after ungetc still
> remain.
There are also two cases to consider:
1) ungetc of the last byte read,
2) ungetc of a different byte value.
Three results are possible:
a. set the file descriptor's position to the strea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Vincent Lefevre on 3/7/2008 6:02 AM:
| On 2008-03-06 22:58:16 -0700, Eric Blake wrote:
| [HP-UX 11]
|> | When reading from the pipe:
|> | c = '#'
|> | c = 'i'
|> | ungetc result = '@'
|> | c =
|> | c =
|>
|> Bug. C99 is quite clear that
tact at 1, but the
ungetc data was lost.
| When reading from the pipe:
| c = '#'
| c = 'i'
| ungetc result = '@'
| c =
| c =
Bug. C99 is quite clear that implementations shall provide at least one
byte of ungetc buffering for all streams, and that it cannot fail if the
Bruno Haible clisp.org> writes:
>
> Eric Blake wrote:
> > Newlib has two bugs - first, fflush is failing to discard ungetc data when
> > changing the underlying fd offset.
>
> This bug is common to all BSD and AT&T Unix derived implementations. For BSD
> systems, I'm committing this fix. For AT
Bruno Haible clisp.org> writes:
>
> Eric Blake wrote on Saturday:
> > Newlib has two bugs - first, fflush is failing to discard ungetc data when
> > changing the underlying fd offset.
>
> Do you know the wording that the newest POSIX has about this?
The ungetc wording is unchanged from POSIX 2
ons, I
don't see an easy fix.
2008-03-06 Bruno Haible <[EMAIL PROTECTED]>
Make fflush after ungetc work on BSD platforms.
* lib/fflush.c (rpl_fflush): Discard ungetc buffer if possible.
* tests/test-fflush2.c: New file.
* tests/test-fflush2.sh: New
Eric Blake wrote on Saturday:
> Newlib has two bugs - first, fflush is failing to discard ungetc data when
> changing the underlying fd offset.
Do you know the wording that the newest POSIX has about this?
The following test program, run on various platforms, gives unconclusive
results.
15 matches
Mail list logo
