Re: ANSI-strict pointer aliasing rules

On Thu, Apr 27, 2006 at 11:08:59AM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
> ... If
> PostgreSQL isn't alias safe - it means that there is casting
> happening, that is not generally accepted as valid, minimizing the
> optimization potential of the code, and certainly not guaranteed to be
> correct. Every cast in C has the potential to contain bugs today, or
> tomorrow when somebody changes the lvalue or rvalue. If the types are
> incompatible, according the compiler, the odds of a bug happening today
> or tomorrow become greater.

You're right, PostgreSQL uses a form of subclassing, so that a (for
example) struct ArrayRefExprState is occasionally referred to using a
(struct ExprState*) or even a (struct Node*). In C, the logical way to
get that to work it by casting, do you have a better way?

The fact is, strict-aliasing only breaks things in the name of
performence.

> I think we can agree on the intrusiveness of the change needing to
> be linear or less to the value of the change. If the fix is simple,
> and it generates a 1% - 2% gain - you are buying both performance,
> and correctness. Personally, I value correctness. I think some would
> value performance though.

The fix is not simple. We wouldn't have disabled it if the fix was
easy. Basically, with strict-aliasing enabled, things break. The
compiler won't identify all the issues for you, how do you know you're
safe? So the system is actually *more* correct with strict-aliasing
disabled, because then it does exactly what the code says...

The two major other places we use casts are converting Datums to their
actual types, and our MemSet which replaces the braindead GCC one.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.