Re: ANSI-strict pointer aliasing rules

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Taral <taralx(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ANSI-strict pointer aliasing rules
Date: 2006-04-27 00:13:21
Message-ID: 1920.1146096801@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> In the grandparent's case I think
> the compiler is being really stupid because it can know the two
> pointers are the same. But I'm sure there are more subtle cases where
> it won't know. PostgreSQL typecasts pointers fairly freely.

Actually, if xlc is behaving as Taral says then I'm pretty convinced
it's *broken*; it is assuming far more than is allowed even by the ANSI
aliasing rules. As I read the spec, ANSI aliasing says that a given
value must always be accessed through equivalent (up to signedness)
primitive types, ie, if you store through an int pointer and fetch
through a long pointer the compiler is allowed to reorder those two
references. In the example Taral gives, both field references are to
fields of type NodeTag. I don't see anything in the spec that allows
the compiler to assume they are distinct variables just because they are
members of different struct types. The spec restriction is defined in
terms of the lvalue type of the particular store or fetch access, not on
what kind of structure it's part of.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-04-27 00:34:54 Re: schema-qualified SET CONSTRAINTS
Previous Message Jim C. Nasby 2006-04-26 23:21:56 Re: Catalog Access (was: [GENERAL] Concurrency problem