Re: Look what I caught! was re:Ada paper critic

["Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net>]

Actually, what the C standard says is that if you have a pointer just after
the end of an array, then the result of dereferencing that pointer is
"unpredictable". Such dereferences can cause segmentation fault, trash some
other memory, or do nothing at all. Any of these outcomes is consistent with
the standard. It's up to the programmer to avoid this behaviour.

Really, all the standard requires is that the compiler can generate a
pointer (not a corresponding object!) just past the right end of the array.
In others words, if we define

    PLANET solar_system[ 9 ];
    PLANET *past_pluto = solar_system + 9;

Then all the standard requires is that past_pluto can be computed, and that
it will compare correctly with pointers to other elements in solar_system,
e.g.

    ( past_pluto > solar_system + 0 ) &&
    ( past_pluto > solar_system + 1 ) &&
    ( past_pluto > solar_system + 2 ) &&
    ...
    ( past_pluto > solar_system + 8 )

That's all that's required. Access *past_pluto, and you're on your own.

Also, the standard only requires a valid pointer to the point just after the
end of an array; no similar rule applies to the beginning of the array. For
example, if you declare

    PLANET *before_mercury = solar_system - 1;

then the standard does NOT require that before_mercury compare meaningfully
with the addresses of the solar_system elements. Of course, the result of
dereferencing before_mercury is unpredictable.