Kenneth Brody wrote On 03/15/07 10:46,:
Eric Sosman wrote:
[...]
> The value of INT_MAX is implementation-defined, so the
output produced by printf("%d\n", INT_MAX) is implementation-
defined. There is nothing "wrong" with the operation, but
a strictly-conforming program must not perform it.
[...]
So, technically speaking, the following is non-conforming?
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
int main(void)
{
printf("INT_MAX is %d\n",INT_MAX);
return(EXIT_SUC CESS);
}
It is conforming, but not strictly conforming. From
section 4, paragraphs 5 and 7 and footnote 4:
A /strictly conforming program/ [...] shall not
produce output dependent on [...] implementation-
defined behavior [...]
A /conforming program/ is one that is acceptable to
a conforming implementation. 4)
4) Strictly conforming programs are intended to be
maximally portable among conforming implementations .
Conforming programs may depend upon nonportable
features of a conforming implementation.
The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!
When the ANSI Standard was young there used to be a lot of
discussions in c.l.c. about just what "strictly conforming" and
"conforming " were, with reams of writing claiming to explicate
the Real Intent of the writers, sort of like lawyers trying to
find an inherent right to broadband in the U.S. Constitution.
Among these cacophonies of opinion one would occasionally find
"proofs" of the non-existence of strictly conforming programs,
or of "non-silly" strictly conforming programs. For example:
- An S.C. program cannot use the #include directive except
for the headers described in the Standard itself, because
the search algorithm for other headers is implementation-
defined. Since the effect of #include "foo.h" is defined
by the implementation, a program that uses it depends on
implementation-defined behavior.
- An S.C. program cannot terminate, because its termination
status is part of its "output" and has an implementation-
defined form, hence a program that terminates produces
output that depends on implementation-defined behavior.
- An S.C. program cannot produce any output at all, because
the output is rendered in an implementation-defined
character encoding.
- An S.C. program cannot allow its output to be affected by
the success or failure of any particular malloc() call,
because the conditions under which malloc() succeeds or
fails are implementation-defined. An S.C. program can
call malloc(), but even if every single malloc() call
returns NULL its output must be unchanged.
.... and so on. Some arguments of this sort were probably raised
for the purpose of amusement (like the fanciful descriptions of
undefined behavior that used to be popular; "demons will fly from
your nose" was just one of many). Some were probably raised to
mock the newly-minted Standard. Some may have been intended as
serious criticisms. All seem to me to have had tiny grains of
truth (however distorted), enough grains to suggest that this
part of the Standard may have feet of slowly-crumbling clay.
--
Er*********@sun .com 
