conforming implementation?

[vippstar]

If the concept of file streams is not possible to be implemented, can
all FILE related functions be "disabled"?
For example:

size_t fwrite(const void *ptr, size_t size, size_t nmemb, FILE
*stream) {
errno = something;
return 0;
}

Perhaps to generalize the question: When the behavior (or return
value) of a function is unspecified by the standard, can an
implementation always choose one behavior?

All replies appreciated.

 

[Keith Thompson]

There are two types of possible conforming implementations, hosted and
free standing. A hosted environment must begin execution of a
program with three FILE streams already open, which can be referred to
by the macros stdin, stdout, and stderr. All the appropriate FILE
functions must be available on these streams.

Yes, but those functions aren't necessarily required to succeed. For
example (using Unix shell syntax), given:

./my_program < /dev/null \

> /this_disk_is_full/out \

2> /this_disk_is_full/err

any attempt to read from stdin or write to stdout or stderr will fail.
I'm not convinced that a hosted implementation in which stdin, stdout,
and stderr are *always* unusable would be non-conforming.

The standard is written to allow for conforming implementations on a
wide variety of systems. One consequence of this is that it doesn't
require a conforming implementation to be *useful* (how could it?).

A free standing environment, on the other hand, is not even required
to provide <stdio.h> or file streams at all.

Right.

 

[Peter Nilsson]

Yes, but those functions aren't necessarily required to
succeed. For example (using Unix shell syntax), given:

./my_program < /dev/null \
2> /this_disk_is_full/err

any attempt to read from stdin or write to stdout or stderr
will fail. I'm not convinced that a hosted implementation in
which stdin, stdout, and stderr are *always* unusable would
be non-conforming.

I would argue that the user who typed the command has
chosen to run the program on a non-conforming implementation.

 

[robertwessel2]

If the concept of file streams is not possible to be implemented, can
all FILE related functions be "disabled"?

I suspect it would be confirming, although not all that useful, if a
hosted implementation failed all fopens, immediately returned EOF for
stdin, and bit-bucketed any writes to stdout and strerr.

 

[Keith Thompson]

I would argue that the user who typed the command has
chosen to run the program on a non-conforming implementation.

An interesting thought, but I disagree. After all, the various I/O
functions are designed to detect errors for a reason.

If I write to stdout and the disk fills up after I've written a
gigabyte of data, and the implementation correctly tells me about the
error, that's not non-conforming. Same thing if it fills up after I
write a megabyte of data. Or a kilobyte. Or none.

 

[Keith Thompson]

I don't agree. A read from /dev/null doesn't /*fail*/, but rather
returns EOF:

[snip]

Good point.

It's difficult to construct a good example of what I'm trying to do,
since if the file is unreadable the error will generally be caught by
the shell before the program is invoked. (Again, I'm using a
Unix-specific example to illustrate a more general point.)

Replace /dev/null with some file or device that can be opened for
reading but on which any read attempts will actually fail and set the
error flag for the stream. I'm still not convinced that this would be
non-conforming. To demonstrate that it *is* non-conforming, you'd
have to find wording in the standard that says it must be possible to
read from stdin without error. It may be ambiguous, but I don't think
there's a clear statement to that effect.