[EMAIL PROTECTED] (Manoj Srivastava) wrote on 10.04.98 in <[EMAIL PROTECTED]>:
> I understand that it is fashionable in comp.lang.c to say that
> undefined behaviour means "It can corrupt memory, re-format your hard
> disk, or make monkeys fly out of your nose; all of these are ISO C
> compliant.", but the standard does make a statement about permissible
> undefined behaviour, and unless such action is documented, it is not
> permitted by the standard.
Bullshit.
The documentation requirement is for implementation-defined behaviour. For
undefined behaviour, "the standard imposes no requirements". No
requirements are no requirements. There is no requirement that such an
action is documented.
It further says "Permissible undefined behaviour ranges from ignoring the
situation completely with unpredictable results, ...", and those
unpredictable results sure include memory corruption, or indeed any of the
other stuff "fashionable in comp.lang.c".
Undefined is *un*defined.
The only interesting question here is if fclose(fp); fclose(fp); is indeed
undefined. (Note that fp=fopen("not.there", "r"); fanything(fp); is
undefined simply because fp is NULL.) I suspect it is, because after the
first fclose(fp); it has "indeterminate value".
MfG Kai
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
