Re: Refining points-to information

George Neuner <>
30 Apr 2006 18:37:14 -0400

          From comp.compilers

Related articles
Refining points-to information (dz) (2006-04-26)
Re: Refining points-to information (George Neuner) (2006-04-29)
Re: Refining points-to information (George Neuner) (2006-04-30)
| List of all articles for this month |

From: George Neuner <>
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 <>
>>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.]


Post a followup to this message

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