Follow-up Comment #2, bug #18170 (project freeciv):

Can't reproduce on my x86_64 machine -- the code gives the right answer for
the example given. A possibly relevant difference is that sparc64 is
big-endian whereas x86_64 is little-endian.

In fact, I'm pretty sure that's what it is. This code relies on dubious casts
between octets and uint32s, and to this end it defines a SWAP() macro that
depends on whether WORDS_BIGENDIAN is defined. Only there's no reason for that
ever to be defined in the Freeciv codebase (the magic to work it out is
protected by _LIBC, which I doubt is defined for us and wouldn't work anyway).
So, I think it can only ever work on little-endian machines.

Probable proof of the pudding: if I define WORDS_BIGENDIAN on my
little-endian machine, create_md5sum() gives the same result as the erroneous
one in comment #0.

My inclination is to find a more portable implementation of md5sum, rather
than trying to fix up this one.

(For the record, before I realised the above I had a look at what I think is
the upstream version (git history
there's not been any significant change since 2005, and I don't see
significant differences in the number-crunching bits between ours and

I assume the effect of this bug is that authentication databases may not be
portable from one server to another of a different architecture; in this case
the server operator will effectively lose all their passwords. I don't think
it affects interoperability between clients and servers?

Conversely, the effect of *fixing* this bug is that any big-endian server
operators will effectively lose all their passwords (unless we put in a
backwards-compatibility wart). Probably not one to drop into a stable release
update, then.


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to