after seeing a warning about strict-aliasing in: divesite.c: create_divesite_uuid()
i think i found a potential problem. the cast at the end of the function can have different results on big/little endian machines, while i'm pretty sure we want the same result on both. if the first 4 bytes of the SHA1 are: 01 02 03 04 we want them serialized in the XML always as: <site uuid=''01020304" .../> on big endian machines that will be the result, while on little endian the result would be: <site uuid=''04030201" .../> for that same divesite (and unless i'm missing something). patch attached. lubomir --
From a8cf9b8cf2e3e8cf67e32d4d4a108566f726672e Mon Sep 17 00:00:00 2001 From: "Lubomir I. Ivanov" <[email protected]> Date: Thu, 1 Oct 2015 18:11:13 +0300 Subject: [PATCH 2/2] divesite.c: preserve byte-order in create_divesite_uuid() Casting as *(uint32_t *)hash can have a different meaning between little and big endian machines, yet the divesite input properties can be the same. To preserve the byte order from the generated SHA1 we form the uint32_t as big-endian ignoring the machine endianness. From there on, the uint32_t can be serialized to XML exactly the same on all machines. Signed-off-by: Lubomir I. Ivanov <[email protected]> --- divesite.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/divesite.c b/divesite.c index e9eed2a..743841e 100644 --- a/divesite.c +++ b/divesite.c @@ -196,7 +196,7 @@ uint32_t create_divesite_uuid(const char *name, timestamp_t divetime) SHA1_Update(&ctx, name, strlen(name)); SHA1_Final(hash, &ctx); // now return the first 32 of the 160 bit hash - return *(uint32_t *)hash; + return hash[0] << 24 | hash[1] << 16 | hash[2] << 8 | hash[3]; } /* allocate a new site and add it to the table */ -- 1.7.11.msysgit.0
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
