Rainer Weikusat wrote:
....
You misunderstand my point.
No, we understand your point, which is how we realized that it's in
need of correction.
... To state that 'the behavious is undefined'
means 'no information regarding this behaviour is available'.
That might be what the phrase means in ordinary English; it's not
what the phrase means in the C standard. The C standard explicitly
defines "undefined behavior" as referring to "behavior ... upon which
THIS INTERNATIONAL STANDARD imposes no requirements" (emphasis
added). You yourself have quoted this text, but seem to have
forgotten the significance of the part that I emphasized: it means
that the behavior is undefined, as far as the standard is concerned,
even if something other than the standard does provide a definition..
Within the context of the C standard, that's what the phrase means;
it's meaning in ordinary English is irrelevant.
That's a pretty good thing because if the standard used your
definition of "undefined behavior" it would require implementors to
detect code which has undefined behavior (which is currently not
required, and infeasible because in some cases it's equivalent to
solving the halting problem). Implementations would have to make sure
that it's impossible to collect any information about what the actual
behavior would be when the behavior is undefined. I don't see any way
for a compiler to render such data collection impossible. In
particular, I don't see any way the implementation can prevent
collection of the following information about the behavior: "the
behavior will be consistent with physical law". Therefore, I'm glad
that the standard doesn't mandate the hiding of such information.
... This
makes (as I have already written) the claim that 'anything can happen'
as wrong as the claim that 'it will cause global warming to stop' or
'nothing will happen' or 'it will cause a to be incremented twice' or
any other conceivable description of any something.
There's a big difference between stating that some particular thing
must happen (which is a direct contradiction of the idea that the
behavior is undefined), and stating that some particular thing may
happen (which is an explicit example of precisely the same idea that
is conveyed by the phrase "undefined behavior"). I can't figure out
your reasoning that leads you to see "As far as the standard is
concerned, such code may cause nasal deamons" as contradictory to
either your definition of "undefined behavior", or the standard's
definition. With your definition, it's quite clear that there's no
information allowing you to reject nasal daemons as a possible
outcome, With the standard's definition, it's clear that the standard
contains no wording which forbids nasal daemons as an outcome. The
only difference is that the standard's definition allows reality to
impose a constraint due to the non-existence of nasal deamons. Your
definition would mandate that the implementation must ensure that
nasal daemons are a possibility, whether or not reality cooperates.
As soon as you (or anyvbody else) claims that such-and-such a thing
may happen, you are not talking about C anymore.
I don't see how you can reach that conclusion - the most plausible
interpretation I can come up with which makes that a reasonable
conclusions is that you are confusing "may" with "must", but that
doesn't seem very plausible either. Saying that "anything can happen"
is a valid way of restating the fact the the C standard fails to
impose any requirements on the behavior. Saying that some particular
thing "may happen" provides a specific example of what "anything may
happen" means, and it's useful didactically because well chosen
examples of behavior that is not prohibitied help motivate developers
to avoid writing code with undefined behavior.