On Wed, Apr 26, 2006 at 04:58:31PM -0400, Tom Lane wrote: > We've looked at this before. There's no way we are buying into the > strict aliasing rules: it's not so much the code we know will break, > as the fear of what we don't know about. gcc, at least, is utterly > useless about warning about constructs that might change behavior > under strict aliasing ... but without fairly reliable warnings of > such problems, we have little hope of getting all the bugs out.
These warnings will never happen. Strict-aliasing could effect
anything, all you'd get would be zillions of useless warnings.
Take for example this innocuous looking code from libpq/hba.c:
static void
parse_hba_auth(ListCell **line_item, UserAuth *userauth_p,
char **auth_arg_p, bool *error_p)
{
char *token;
*auth_arg_p = NULL;
if (!*line_item)
{
Strict aliasing says that 'line_item' and 'auth_arg_p' can't point to
the same location because they are different types. Hence the
store/load could be overlapped safely. *We* know that will never be a
problem, but the compiler can't know, so it has to assume one way or
the other. With no-strict-aliasing, it can't reorder and it might add
wait-states instead, just in case (CPU dependant obviously).
The compiler could warn you about this, but it'd be useless since you
can't do anything about it anyway. 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.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to
> litigate.
signature.asc
Description: Digital signature
