Re: A question regarding Q20.1 from c-faq.com

Mark McIntyre wrote:
Richard Heathfield wrote:
Mark McIntyre said:

Richard Heathfield wrote:
santosh said:

<snip>

I'm sure I'm missing something simple here, but to me, if
sizeof(char)==sizeof(int), it seems impossible to simultaneously return
all possible character values and the out-of-band value EOF.
All that this actually breaks is the assumption that a value of EOF
necessarily means "it failed"
Yes but its obligated to mean that - since many functions are obligated
to return EOF on error conditions.

I agree that it means that - but where does the Standard say that it can
*only* mean that? :-)

Smiley noted. But since some functions are obligated to use EOF to
indicate an error, its completely correct to check for that return.

I would disagree; for the small set of routines where EOF is returned
through the same channel as valid characters, relying solely upon an
EOF value to diagnose an error/eof condition is the wrong approach,
unless the program tests to make sure that it does so only if
UCHAR_MAX < INT_MAX.

If in some implementations a programmer can't distinguish the error
return from a non-error return, ...

Since it's always possible to distinguish an error return from a non-
error return by use of ferr() and feof(), that's never an issue.

... code which is completely conforming will
malfunction. ...

There's no category named "completely conforming" defined by the
standard. The standard provides only two code-conformance categories;
one of which ("conforming code") is far too broad to be of any use
whatsoever, other than being a political compromise that allowed the
standard to be approved. The other category ("strictly conforming
code") is far too strict to describe any significant fraction of real-
world programs; it's useful for discussing the meaning of the
standard's requirements, but not for much else. However, what we're
doing right now is discussing the meaning of the standard's
requirements, so that's the term I'll assume you're referring to.

A program that is "strictly conforming", is prohibited from producing
output which depends upon implementation-defined behavior. Code such
as you describe has behavior which depends upon whether or not
UCHAR_MAX > INT_MAX, which is implementation-defined. If that behavior
has any visible effect on the output of the program, then the code is
not strictly conforming.

... My POV is that if an implementation can't translate and
_execute_ a conforming programme correctly, it can't be a properly
conforming implementation.

I believe that a conforming implementation of C with UCHAR_MAX >
INT_MAX could translate and execute a program such as you describe
correctly; it wouldn't behave as intended by the developer, but it
would behave in a manner which is completely consistent with the
standard's requirements for the behavior of such code.
.

Relevant Pages

  • Re: A question regarding Q20.1 from c-faq.com
    ... All that this actually breaks is the assumption that a value of EOF ... If in some implementations a programmer can't distinguish the error return from a non-error return, code which is completely conforming will malfunction. ... CLC FAQ ...
    (comp.lang.c)
  • Re: EOF
    ... Richard Heathfield writes: ... The only requirement for EOF is that it be negative. ... it must also have integral type. ... would not be conforming. ...
    (comp.lang.c)
  • Re: extended operators
    ... In standard C, ... even in a strictly conforming program, ... if I were just making a "c-like" language, well then, I would have probably largely disregarded the standard altogether, choosing instead to go my own way with pretty much everything I didn't agree with... ... and then, there is a strictly conforming implementation, for which all code works exactly as specified. ...
    (comp.std.c)
  • Re: calloc/free: a preplexing observation
    ... Sure the standard only really requires that one hypothetical program ... Other programs, even strictly conforming ones, can fail ... >> whether lazy allocation is conforming or not, ...
    (comp.lang.c)
  • Re: Anyone object to the following change in libc?
    ... TL>> specifier. ... Is it an EOF? ... TL>ISO C standard" refers to "c89", which is the version of the C ... "The c89 utility (which specified a compiler for the C Language specified ...
    (freebsd-current)