Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group