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

ANSI-strict pointer aliasing rules

From: Taral <taralx(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: ANSI-strict pointer aliasing rules
Date: 2006-04-26 20:45:00
Message-ID: fa0147d90604261345s24b191bcj5a612cc918e31f1d@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
I ran afoul of these rules the other day when compiling pgsql 8.1 on
AIX. The configure scripts are set up to look for "xlc" instead of
"cc", and that command invokes cc with "-qalias=ansi", the ANSI-strict
pointer aliasing mode.

Specifically, in this mode, the compiler assumes that accesses via
pointers of different types never alias. Unfortunately, this breaks
all of the Value construction code, because we end up with (for
example):

Node *n = palloc0fast(...);
n->tag = T_VALUE;
Value *v = (Value *) n;
v->tag = T_STRING;

And aggressive compiler optimization can reorder these two tag
assignments, resulting in the bizarre "Unrecognized node type: 650"
message.

The fix is one of two things:

1. Change the "tag" element of structures to be a Node, and access the
tag via it: Major code change, allows Node to change in the future for
instrumentation et cetera.
2. Make the makeNode macro cast to the derived structure before
assigning the tag: Minor code change, makes assumptions about derived
structures.
3. Get configure to select "cc" instead of "xlc": No code change,
loses some performance.

--
Taral <taralx(at)gmail(dot)com>
"You can't prove anything."
    -- Gödel's Incompetence Theorem

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-04-26 20:45:48
Subject: Re: [HACKERS] Enhanced containment selectivity function
Previous:From: Tom LaneDate: 2006-04-26 20:33:06
Subject: Re: [HACKERS] Enhanced containment selectivity function

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