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
    integer overflow.

Well, you got the "unpredictable results", and it's easy to argue that
a core dump is "termination ... with the issuance of a diagnostic
message".

--apb (Alan Barrett)