brk's zero-fill behavior on VAXen (useful undefined checks)

[Karl Heuer]

In article <363 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
>[Initializing to zero is inferior to] a constant garbage value (eg: 0x3e).
>Now, if a pointer was to be used that lived in such memory, it would be:
>0x3e3e3e3e, a value that will cause most CPU's to give a bus-error or seg
>fault, because (1) ... it is an odd-address,

A minor quibble here; 0x3e is even.

>Perhaps for the sake of run-time checking available with languages such
>as Pascal on a 32-bit machine you could sacrifice one state of
>the 4G available to be classified as 'undefined'.  An obvious state is
>[the most negative number on two's complement machines].

Of course, using this value throws away the benefit of having all bytes in
the "garbage value" be the same.  But anyway...  I don't mind losing this
value for objects used arithmetically (I don't trust operations on MAXNEG
anyway), but you'd have to make an exception for objects used as bit-patterns
("unsigned" in C).  (I had problems with this once, using a language that
enforced such a "garbage value".  I think it was a graphics program, and it
turned out to be impossible to draw a certain one-bit pattern.)

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
P.S. I like the way VAXen do this with floating point (the result of some
operation is NaN, which triggers an FPE on the *next* usage, giving the user
a chance to test for it first).