[collectd] [PATCH] Fix gcc-4.4 strict-aliasing issue

[Sebastian Harl]

Hi,

(Just a quick comment since I'm short of time ...)

On Wed, Mar 11, 2009 at 12:50:19AM +0100, Alan Pevec wrote:
> On Fri, Mar 6, 2009 at 7:21 PM, Florian Forster <octo at verplant.org> wrote:
> > I have doubts about using the unions in that way though because I don't
> > quite see the advantage. I suspect `-fstrict-aliasing' will work when
> > using GCC on this file. Does the rest of collectd compile with
> > `-fstrict-aliasing'? I'd be surprised, to be honest, because I'm sure we
> > use similar casts in other places. Is that optimization turned on by
[...]
> We could either add */*/Makefile.in or, better, fix all warnings and
> remove that sed workaround :)

Ack - fixing that is, of course, the preferred solution ;-)

> > default when using GCC 4.4?
> 
> Yes, this showed up during Fedora rawhide mass-rebuild with gcc-4.4
> see https://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html
> It doesn't show up in F10 with older gcc, cf
> http://kojipkgs.fedoraproject.org/packages/collectd/4.5.3/1.fc10/data/logs/x86_64/build.log

Imho, this should rather be fixed in GCC. The whole Berkeley sockets
interface relies on the fact that there is a correctly implemented
"inheritance" between the sockaddr* types, so not being able to cast
those types to each other would break about any networking software.
It's true that, in general, such casts should be avoided as, again in
general, this might cause undefined behavior. However, the compiler
should be able to detect and correctly handle (i.e. avoid the warning)
cases where this does not cause any problems such as in this case.

> I found the union approach in a libvirt patch:
> http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=07a0ff22d5869794e6d721a1706aa9dd46760858;hp=05dc4c6062d07a34678133d5dc68280d500db10d
> 
> Union is still cleaner than direct pointer casting, imho, and could
> help compiler optimizations,
> see http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

The problem with the union approach is that, according to annex J of the
ISO/IEC C99 standard, the behavior is undefined when accessing a
different union member than the last one stored into. So, if we use that
approach, some other compiler might, correctly, complain about that as
well. However, I'm not sure if the standard does specify some way how to
correctly handle such cases, so I don't really know how to do it right
... :-/

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090311/cdd9d9fd/attachment.pgp