This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some strict aliasing related fun


> Now that you mention it, turning on "-W -Wall -fstrict-aliasing" does
> give a warning about "dereferencing type-punned pointer will break
> strict-aliasing rules" (but not if I don't turn on -W -Wall) ... for
> some reason I always thought "-W -Wall" warned about everything
> regardless of optimiser settings ... chalk one up to experience I guess!

You should be able to use -Wstrict-aliasing as well.

> Yup ... I'm not sure what the alternative is though given at the end of
> the day this has to go through htonl/ntohl in preparation for network
> transmission and I'm not aware of any word-length-transparent way of
> doing THAT ... of course, it's possibly more due to my ignorance than
> there actually not being a way, if there is I'd be most happy to find
> out! :-)

Someone should correct me, but if you really have to go through a long
generically, I don't see why you couldn't go through an unsigned int
first.  Then push the unsigned int into the lower 4-bytes of the
unsigned long and then reverse it coming back.  I don't know if your
system allows for any such consistency.

> I could and will probably end up doing that ultimately ... I just was of
> the impression that the sort of casting I was using was reasonably
> widely accepted and was a little confused when it worked fine up until
> when I tried compiling it on a GCC 4.x system (at which point it gave me
> random stack-corrupting segfaults - always a pain to debug!) ... ah well

I don't know the changes there but the -fstrict-aliasing option has
been enabled in -O2 for a while.  If warnings were surpressed then the
problem was just hidden for a while.

> ... I notice this sort of casting in a few other libraries I use - and
> I've just found that their autoconf'd makefiles all seem to have
> -fno-strict-aliasing in them so I might just do that for now so I can
> actually get some results!

If you're developing a library with external headers, be careful about
what type of aliasing you put into functoins defined in a header since
they might not be used in a program compiled without strict aliasing.

corey


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]