Re: whats wrong with analysizing pointers this way ?

Dave Thompson <david.thompson1@worldnet.att.net>
5 Mar 2006 02:19:16 -0500

          From comp.compilers

Related articles
whats wrong with analysizing pointers this way ? drizzle76@gmail.com (dz) (2006-02-19)
Re: whats wrong with analysizing pointers this way ? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-02-20)
Re: whats wrong with analysizing pointers this way ? jvorbrueggen-not@mediasec.de (=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=) (2006-02-24)
Re: whats wrong with analysizing pointers this way ? shreyas76@gmail.com (shrey) (2006-02-24)
Re: whats wrong with analysizing pointers this way ? david.thompson1@worldnet.att.net (Dave Thompson) (2006-03-05)
Re: whats wrong with analysizing pointers this way ? jvorbrueggen@mediasec.de (=?ISO-8859-1?Q?Jan_Vorbr=FCggen?=) (2006-03-11)
| List of all articles for this month |

From: Dave Thompson <david.thompson1@worldnet.att.net>
Newsgroups: comp.compilers
Date: 5 Mar 2006 02:19:16 -0500
Organization: AT&T Worldnet
References: 06-02-133 06-02-147 06-02-156
Keywords: analysis

On 24 Feb 2006 09:38:14 -0500, Jan Vorbrüggen
<jvorbrueggen-not@mediasec.de> wrote:


> > Where "pointer" does not only mean, that such variables contain
> > addresses, that's just a convention. You also must open the can of
> > worms, by allowing access to memory locations, using the *values* stored
> > in pointer variables, and by introducing pointer arithmetic, so that
> > references can end up in some variable near the variable pointed to, or
> > in unallocated memory.
>
> That additional functionality depends, of course, on the language those
> pointers are used in. Fortran, for instance, has pointers that just don't
> allow such things to be done; thus, the chance of worm-holes occuring is
> quite low - actually, if you only write standard-conforming programs, there
> are none.
>
Well, standard-conforming C (et seq) and Ada and PL/I don't have
pointer bugs either, since buggy use violates each of the standards,
but in all of them plus Fortran the implementation isn't required to
diagnose such bugs as it is generally impossible at compile time and
often unacceptably inefficient at run time.


What Fortran and Ada do, and PL/I to an extent, is provide safe and
arguably better ways to do many of the things that require pointers in
C and even C++. Thus 'good' idiomatic Fortran has on average (much)
less risk of pointer bugs because it has on average less pointers.


And the first two allow you to (mostly) explicitly restrict which
things can be pointed to, which if used prudently reduces the
"(nearly) everything is at risk" problem the OP was asking about.
- David.Thompson1 at worldnet.att.net



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.