deviceid / diveid weirdness

Thiago Macieira thiago at macieira.org
Fri Nov 22 13:15:18 UTC 2013


On sexta-feira, 22 de novembro de 2013 12:48:06, Dirk Hohndel wrote:
> Linus, Thiago,
> 
> you are the two people that I think of when I wonder about strange
> things that C code does to me that might involve weird corner cases, odd
> casts, or something else that is just plain puzzling.
> 
> Please take a look at bug #164 http://trac.hohndel.org/ticket/164
> 
> Some users get deviceid and diveid entries above 0x80000000 "truncated"
> into 0x7fffffff. But apparently only after downloading additional dives
> on top of existing ones.
> 
> I have two dive computers with MSB set and don't encounter this - I also
> have several dives with such diveids. And I even used (for a while) the
> same dive computer as the second person reporting the problem.
> 
> I have poked at the fact that libdivecomputer.h defines deviceid and
> diveid as unsigned int (which on most modern computers is likely 64bit)
> instead of uint32_t. But these are signed values. Nothing should
> "truncate" them to MAX_INT...

I can only think of one operation that clamps down a positive number to 
MAX_something: saturated conversions on SSE. That's actually what I used to 
convert UTF-16 to UTF-8 in Qt 5.3: a saturated conversion from signed 16 to 
unsigned 8 bit, which changes everything > 0xff to 0xff and everything negative 
to 0.

However, I *really* doubt that this is the case here. And I can't remember of 
any SSE instruction that converts 64-bit to 32-bit signed or 32-bit unsigned 
to 32-bit signed like that.

So I'm going to guess that the problem is not a transformation of a number 
already in memory. My money is in the generation of said number from XML.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20131122/6669b4fe/attachment.sig>


More information about the subsurface mailing list