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 ...)
Cheers!
- Raymond
