[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fflush after ungetc

From: Eric Blake
Subject: Re: fflush after ungetc
Date: Fri, 28 Mar 2008 23:14:17 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080213 Thunderbird/ Mnenhy/

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 require an fflush
replacement by any of the current tests in fflush.m4.  Therefore, cygwin
fails test-fflush2.c: the fgetc on line 74 returns '!' (original offset 1)
and not '/' (offset 2).  This is a release blocker for M4 1.4.11 (which in
turn is a blocker for Autoconf 2.62).  However, the block is not a severe
one, since I can use gnulib-tool --local-dir in M4 to cripple
test-fflush2.c as too immature to be reliable.

At this point, I would even be happy with a solution that enforces 1a
(since M4 relies on that behavior, and both cygwin and Linux provide it),
and leaves condition 2 ambiguous (particularly since cygwin does 2a while
Linux does 2b); after all:

| ungetc with a different byte is insane anyway. I'm discussing it only
| the standard allows it.

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 open a glibc bug report.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]