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) |
From: | =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen@mediasec.de> |
Newsgroups: | comp.compilers |
Date: | 11 Mar 2006 23:32:23 -0500 |
Organization: | MediaSec Technologies GmbH |
References: | 06-02-133 06-02-147 06-02-156 06-03-012 |
Keywords: | analysis |
Posted-Date: | 11 Mar 2006 23:32:23 EST |
> 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.
Well, such things as arbitrary pointer arithmetic just can't be
expressed in Fortran. The compiler is not required to diagnose
dangling pointers and out-of-bounds array accesses - still a big
problem, but at least the latter can be checked at run-time in almost
all cases.
> 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.
Yes, quite agreed. And the extension of the places you can use
ALLOCATABLE variables that occured between, as it were, F95 and F03
removed another large class of cases where pointer problems could
occur.
> 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.
If you want to unrestrict such restrictions, you have to do it
explicitly - which is OK with me: you have a syntactic way of saying
"here be dragons" that serves several useful purposes.
Jan
Return to the
comp.compilers page.
Search the
comp.compilers archives again.