Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Out-of-bounds pointers
Message-ID: <11232@smoke.BRL.MIL>
Date: 6 Oct 89 19:49:42 GMT
References: <1009@mtxinu.UUCP> <12570028@hpclwjm.HP.COM> <868@crdos1.crd.ge.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 48

In article <868@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <12570028@hpclwjm.HP.COM>, walter@hpclwjm.HP.COM (Walter Murray) writes:
>|  Doug Gwyn:
>|  > It's not even "legal" to compute an invalid address, whether or not
>|  > it is dereferenced.
>  While this is obviously true, I have never understood the rationale of
>this decision. Given that (a) there are existing programs which do this,
>for reasons other than sloppy programming,

How could they?  If a computation produces a genuinely meaningless
result, how can a reasonable program rely on it?

>(b) most implementations happily allow this,

You mean, most implementations don't provide any sensible check for
this.  The worst bugs I've found in UNIX software were due to
computing invalid pointers as an intermediate step in an algorithm.
When it happened to work, it was BY ACCIDENT.  When it failed, it
was a MYSTERY (until I finally tracked it down).  If you think that
this is desirable behavior, then you're nuts.

>(c) if you are allowed to declare an auto pointer at all then obviously
>the hardware supports uninitialized pointers,

Obviously?  Allocation of storage is not the same as accessing its
contents.

>I fail to see what benefit is gained.

The "benefit" is that faster, more natural C implementations are
permitted on architectures where this is an issue.

Another benefit is that we do not have to figure out rules for
assigning meanings to inherently meaningless address-arithmetic
results, as we would be obliged to do if they were guaranteed
legitimate by the standard.

The final benefit is to bring the non-portable (and often unsafe)
nature of such operations clearly before the eyes of the C
programming public.

>Could someone clarify this, since it certainly is not prevailing
>practice? 

I have no idea what you mean by "prevailing practice".  The only
significant prevailing C "standard" was K&R 1st Edition Appendix A.
It certainly did not promise that randomly computed addresses would
always be valid pointer values.