Hi,
>>"Kai" == Kai Henningsen <[EMAIL PROTECTED]> writes:
Kai> Bullshit.
Bullshit? And this is supposed to be a technical discussion?
Can you not engage in civilized discourse without resorting to
invective? Do you realize that is generally the case with a weak
argument?
Kai> The documentation requirement is for implementation-defined
Kai> behaviour. For undefined behaviour, "the standard imposes no
Kai> requirements". No requirements are no requirements. There is no
Kai> requirement that such an action is documented.
Have you actually read the standard? I even quoted parts of
IEEE 1.6 for you. I shall do so again.
----------------------------------------------------------------------
1.6 Definitions of terms
o Undefined Behaviour -- behaviour, upon the use of a nonportable or
erroneous program construct, of erroneous data, or of inderminately
valued objects, for which the standard imposes no
requirements. Permissible undefined behaviour ranges from ignoring
the situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
charecteristic of the environment (with or without the issuance of a
diagnostic message), to terminating a translation or execution (with
the issuance of a diagnostic message).
If a "shall" or "shall not" requirements that appears outside
of a constraint is violated, the behaviour is undefined. Undefined
behaviour is otherwise indicated in this standard by the words
"undefined behaviour" or by the omission of any explicit definition
of behavior. There is no difference in emphasis among these three;
they all describe "behaviour that is undefined."
o Unspecified behaviour -- behaviour, for a correct program construct
and correct data, for which the standard explicitly imposes no
requirements.
______________________________________________________________________
See where it says "Permissible undefined behaviour"? Ignoring
the second fclose completely (which may have unpredictable results),
"behaving during translation or program execution in a documented
manner charecteristic of the environment", or terminating (in which
case an error message is required: anything else is a violation of
the standard. Period.
All under "Permissible undefined behaviour".
And yet you use invective and state things in direct
contradiction of the standard.
Kai> Undefined is *un*defined.
Oh, despite what the standard says, if you say it is
undefined, it is undefined. Wonderful.
Kai> The only interesting question here is if fclose(fp); fclose(fp);
Kai> is indeed undefined. (Note that fp=fopen("not.there", "r");
Kai> fanything(fp); is undefined simply because fp is NULL.) I suspect
Kai> it is, because after the first fclose(fp); it has "indeterminate
Kai> value".
Quite so.
manoj
--
"If the conjecture `You would rather I had not disturbed you by
sending you this.' is correct, you may add it to the list of
uncomfortable truths." Edsgar Dijkstra
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
