Subject: Re: lib/34632
To: None <gnats-bugs@NetBSD.org>
From: Alan Barrett <email@example.com>
Date: 09/27/2006 22:00:33
Other people have explained that the behaviour is undefined,
but I'll back it up with quotes from the C99 standard (ISO 9899:1999).
On Wed, 27 Sep 2006, Antony Dovgal wrote:
> I mean, *I* can live with that because I don't use it, but "undefined
> value" in my pov doesn't include "segfault", I expect to get an
> undefined integer value, that's it.
It's not an "undefined value", it's "undefined behaviour".
See section ISO 9899:1999 section 7.4:
The header <ctype.h> declares several functions useful for
classifying and mapping characters. In all cases the argument is an
int, the value of which shall be representable as an unsigned char
or shall equal the value of the macro EOF. If the argument has any
other value, the behavior is undefined.
"The value of which shall be representable [...]" means: It's the
application programmer's responsibility to ensure that the value
is representable [...]". "[The] behavior is undefined" means "If the
application programmer fails in their responsibility, then the
implementation may do or not do anything at all".
The definition of "undefined behavior" in section 3.4.3 says:
undefined behavior: behavior, upon use of a nonportable or erroneous
program construct or of erroneous data, for which this International
Standard imposes no requirements.
NOTE: Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving
during translation or program execution in a documented manner
characteristic 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).
EXAMPLE: An example of undefined behavior is the behavior on
Well, you got the "unpredictable results", and it's easy to argue that
a core dump is "termination ... with the issuance of a diagnostic
--apb (Alan Barrett)