[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] Simplify use of apr_hash_this()

From: Philip Martin <philip_at_codematters.co.uk>
Date: Tue, 30 Jun 2009 19:37:14 +0100

Branko ─îibej <brane_at_xbc.nu> writes:

> Strictly speaking, no, it's not valid. And aliasing *might* break
> if/when GCC does whole-program optimization. Neither is likely to cause
> real problems, though.

Is whole program optimisation required before aliasing becomes a
problem?

This is one way to initialise a pointer:

     svn_wc_entry_t *entry;
     svn_wc_entry_t **p = &entry;
     *p = 0;

but this:

     svn_wc_entry_t *entry;
     long *p = (void*)&entry;
     *p = 0;

violates the aliasing rules. If long is the same size as a pointer
then the write should set the correct bytes to zero. However even if
that happens an optimising compiler can assume that the write to *p
doesn't change entry and can thus assume that entry is still
unitialised.

So in the same way

     svn_wc_entry_t *entry;
     apr_hash_this(... (void*)&entry);

can the compiler assume that calling apr_hash_this doesn't modify
entry? Does it need whole program optimisation to make this
assumption? It's because I can't answer questions like this that I
would rather have temporary variables and no casts.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2366802
Received on 2009-06-30 20:37:40 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.