This is the mail archive of the 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

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.
Sorry, I'm a little confused ... if a float on a 64 bit machine is actually 64 bits long, I'm not sure going through an unsigned int would help - I *think* you'd have to have some check that, if needed, turned on a conversion to a 32 bit IEEE float before it went into endian conversion ... now that I think about it, there HAS to be a well defined, standard way of doing 32/64 bit compatibility issues (just like hton/ntoh were well defined ways of dealing with endian-ness issues) ...

Actually, if you're referring to my use of "unsigned long", my real code refers to it as "uint32_t" (which I understand is what ntoh/htonl actually uses anyway) - I didn't want to include additional header files in the example so I used unsigned long instead ... doesn't quite solve the portability problem but at least it *should* mean any problems get flagged at compile time.

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.
Funnily enough, under GCC 2.9.5 and 3.3.6, compiling with "-O2 -W -Wall" or "-fstrict-aliasing -W -Wall" does give the same type punning warning but doesn't break - it looks like it only broke in 4.x ... perhaps the early versions were a threat and the new version made good on it ;-)

Actually, -fstrict-aliasing by itself doesn't break this, even in GCC 4.x ... it's -fstrict-aliasing along with some other at-times-unknown combination of optimisations (and different optimisations depending on how the code was structured - see my overly verbose example in my initial post) that -O2 does that ultimately broke things for me ...

That reminds me ... is there any easy way of getting a list of all the optimisations that are done for -O/-O2/etc. and not just the ones that can be manipulated with flags? I notice that the manpage says something along the lines of only the ones that can be turned on/off with flags are listed there (and indeed, in one of the cases, if I manually put all the optimisation flags mentioned in the manpage for -O1 and -O2 onto the compile line it doesn't actually break!).

... 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.
Good point ... if this ever does end up being used by someone else I'll make sure I document it (I'll fix it in my code but there's other code here which appears to also have a similar problem ...)


- Raymond

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