Related articles |
---|
Refining points-to information drizzle76@gmail.com (dz) (2006-04-26) |
Re: Refining points-to information gneuner2@comcast.net (George Neuner) (2006-04-29) |
Re: Refining points-to information gneuner2@comcast.net (George Neuner) (2006-04-30) |
From: | George Neuner <gneuner2@comcast.net> |
Newsgroups: | comp.compilers |
Date: | 30 Apr 2006 18:37:14 -0400 |
Organization: | Compilers Central |
References: | 06-04-151 06-04-174 |
Keywords: | analysis |
Posted-Date: | 30 Apr 2006 18:37:14 EDT |
On 29 Apr 2006 10:54:35 -0400, George Neuner <gneuner2@comcast.net>
wrote:
>>
>>You can certainly tell by examination whether a particular local
>>variable's address was taken, but you can't assume no aliasing in the
>>negative case if any other local variable's address was taken and
>>arithmetic was performed on that pointer.
>>
John replied:
>You can certainly assume that a local that never has its address taken
>isn't aliased. I realize that people write code like this snippet, but
>it's forbidden by the standard and people deserve what they get;
>
> int a;
> int b;
> int c;
>
> int *p = &a;
> p[2] = 12; // change c
I was actually thinking about the problems associated with fixed size
arrays and filler functions, and about C strings and manipulations
thereof. You're certainly correct that few people would write
something like your example, but it's all too easy in C/C++ to make
indexing mistakes and few programmers ever take the time to fully
qualify pointers wherever possible so the compiler can help to catch
errors. The average programmer is much more likely to write
int *p;
or int f ( int *p );
rather than
int (*p)[10];
or int f ( int (*p)[FILLSZ] );
which tells both the programmer and the compiler (to some extent) what
size array is expected. In the second example lint and most decent
compilers will signal an error if you tried to pass "p" to function
f() with FILLSZ <> 10.
The specific forms typically require more (and more involved) casting
to satisfy the compiler ... so programmers tend not to use them.
There are certainly times when you need to use the more generic
declarations, but IME most programmers simply use the generic forms
regardless because they requires less thinking up front. The
programmer pays the piper later when debugging is harder.
[I am not addressing C++ and dynamic array classes. They mitigate
and/or solve a whole host of problems and are clearly to be preferred
if the application can tolerate their use. But they are not
appropriate for all environments.]
George
Return to the
comp.compilers page.
Search the
comp.compilers archives again.