deviceid / diveid weirdness

Lubomir I. Ivanov neolit123 at gmail.com
Fri Nov 22 13:48:20 UTC 2013


On 22 November 2013 23:25, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> On 22 November 2013 23:22, Dirk Hohndel <dirk at hohndel.org> wrote:
>> On Fri, 2013-11-22 at 13:12 -0800, Linus Torvalds wrote:
>>> On Fri, Nov 22, 2013 at 12:48 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> >
>>> > Some users get deviceid and diveid entries above 0x80000000 "truncated"
>>> > into 0x7fffffff. But apparently only after downloading additional dives
>>> > on top of existing ones.
>>>
>>> Ugh.
>>>
>>> I think we need to fix hex_value() in parse-xml.c to use "strtoul()".
>>>
>>> The problem is hidden on 64-bit builds.
>>
>> strtoul() is supposed to return unsigned long int. Which on a 32bit
>> architure is supposed to be 32bit.
>>
>> Our IDs are max 8 hex digits. So nothing should overflow.
>>
>> And even if it did... strtoul returns ULONG_MAX when things overflow...
>> that doesn't explain why we are getting 32bit LONG_MAX as result :-(
>>
>
> i think that linus is on the right path...
>
> char *i = "0x80000001";
> printf("0x%08x\n", strtol(i, NULL, 16));
> printf("0x%08x\n", strtoul(i, NULL, 16));
>
> where the output would be:
> 0x7fffffff
> 0x80000001
>
> i think strtol(), just does that.
>

if this is standard library accurate:
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/libkern/strtol.c

0x80000000 and above numbers get clamped to LONG_MAX, but on a 32bit
desktop LONG_MAX could be the same as INT_MAX.

lubomir
--


More information about the subsurface mailing list