🚀 go-pugleaf

James M. Cowen wrote:
> 
> Is the result of fflush(stdin) a fortuitous consequence of "undefined
>                         ^^^^^
> behavior" as described in ISO/ISE 9899 section 7.9.5.2 (p. 129) i.e.
> it seems to act as if it does purge the streams buffer (ala fpurge()).
> 
> I've found the action to "work" on Solaris 2.X (and x86), hpux 9.X
> 10.X, and Esix 5.4.1..
> 
> On Linux 1.1.59, the result of fflush(stdin) results in errno being set
> to an error message number (either Illegal Seek or Unknown Error ...
> depending on the sequence of inputs to the standard input.)
> 
> A disclaimer: I'm aware this group is not concerned with POSIX.1,
> never-the-less, what about the following:
> 
> But, if I look over the POSIX.1 standard (ISO/ISE 9945), it seems to
> imply under certain conditions, it's allowable to associate fflush()
> with a stream open'd as read or update (pp. 159-161, 288-290 and 307), yet
> in the Rational Section (p. 290, section B.8.2.3.4), POSIX.1 states:
> 
>      "There is no additional rationale provided for this subclause."
> 
> In short, I'm confused, can someone clarify how one would use fflush()
> in a portable fashion ... no that's not what I want to ask.  Don't use
> fflush() on a read/update stream,  that seems obvious given ANSI C, 
> but it "works" on POSIX.1 systems, but POSIX.1 indicates it accepts 
> the ANSI C standard, but ... I hope you get the drift of my question.

There is no conflict here.  ISO C does not impose any requirements
on what an implementation of fflush() should do if it is called
with an input stream as its argument.  An ISO C implementation
can therefore do anything its designers think is reasonable.  On the
other hand a program that calls fflush() on stdin is not a strictly
conforming program (see ANSI/ISO 9899-1989 Section 4) since it relies
on behaviour that is not defined by the standard.

POSIX.1 gives a specification for what fflush() should do if called
on an input stream: specifically, that it should discard any pending
data.  This is not in conflict with ISO C but places an additional
restriction on an ISO C implementation.  Some of the behaviour that
was left undefined by the ISO C standard becomes defined in an
environment that conforms to POSIX.1.  A program that calls
fflush() on stdin is therefore guaranteed to work in the same way
(at least as far as that call is concerned) on any system that
conforms to the POSIX.1 standard but not on all systems that
conform to ISO C.

It is important to remember that portability is not an absolute
quality but that there are different degrees of portability.
A strictly conforming C program is guaranteed to run and to behave
in the same way in any hosted ISO C environment.  A program that
conforms to POSIX.1 is guaranteed to run and behave in the same way
in that subset of ISO C environments that also conform to POSIX.1.
This can be carried further: for example a program that conforms
to the Single Unix Specification (the 1170 spec) is guaranteed
to run and behave in the same way in that subset of POSIX.1
environments that also conform to the Single Unix Spec.  There is
an obvious trade-off to be made at each step: each step adds
functionality or convenience but adds restrictions on portability.
The cost of restricting portability has to be weighed against the
loss of function or convenience that would be incurred by not
accepting this restriction.

--

Chris Flatters
cflatter@nrao.edu