Re: Refining points-to information

George Neuner <gneuner2@comcast.net>
29 Apr 2006 10:54:35 -0400

          From comp.compilers

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)
| List of all articles for this month |

From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: 29 Apr 2006 10:54:35 -0400
Organization: Compilers Central
References: 06-04-151
Keywords: C, optimize
Posted-Date: 29 Apr 2006 10:54:35 EDT

On 26 Apr 2006 01:13:49 -0400, "dz" <drizzle76@gmail.com> wrote:


>Spefically, if a local
>variable's address is not taken, perhaps it can be not included in the
>points to set. Similarly. can't I assume that if it is a int* then it
>would not point to a function. Are these also unreasonable ?


It's very hard to reason intelligently about pointers in C/C++ because
these languages allow pointer arithmetic and casting conversions.


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.


Similarly wrt limiting the set of types that could be pointed to ...
you're also short of luck because any type of pointer may be cast to
or from a void pointer. Realistically, you can't assume the type of
the target matches the type of the pointer to it unless you also know
the entire chain of casts and arithmetic that has been performed.


George
[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


You are correct that you can't make type assumptions without very
thorough and often impossible type analysis. - John]





Post a followup to this message

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