Re: Signedness of sizeof()
Re: Signedness of sizeof()
- Subject: Re: Signedness of sizeof()
- From: Clark Cox <email@hidden>
- Date: Tue, 16 Mar 2010 21:07:53 -0700
On Tue, Mar 16, 2010 at 6:20 PM, Andreas Grosam <email@hidden> wrote:
>
>
> On Mar 17, 2010, at 12:14 AM, Hamish Allan wrote:
>
>> I am using a piece of library code in which an int is compared with
>> the result of a sizeof(). The comparison appears to be unsigned, i.e.
>> the int is coerced into an unsigned int. To illustrate:
>>
>> int a = -1;
>> if (a >= sizeof(a))
>> {
>> NSLog(@"%d >= %d", a, sizeof(a));
>> NSLog(@"%u >= %u", a, sizeof(a));
>> }
>>
>> outputs:
>>
>> 2010-03-16 23:09:41.666 SizeofTest[17587:a0f] -1 >= 4
>> 2010-03-16 23:09:41.672 SizeofTest[17587:a0f] 4294967295 >= 4
>>
>> Evidently the library author is using an architecture in which the
>> comparison is made signed.
> I doubt, it rather looks somewhat sloppy. According the spec, sizeof() returns size_t, which is an unsigned integer. In the operator>=, the signed int will be implicitly converted to unsigned int by preserving the bit pattern.
Close; it's not the bit pattern that is preserved, it is the value,
wrapped to fit within the range of the unsigned type, that is
preserved (i.e. -1 gets converted to the maximum value representable
by the unsigned type, -2 is one less, etc.). While, on a two's
complement system, that amounts to the same end result, C is not
limited to two's complement system.
> I would really change his code, either using size_t for the variables a (and ensuring it doesn't get negative), or doing the explicit int cast. Mixing signed and unsigned ints in operators are potentially error prone.
>
>> Rather than change his code to cast the
>> result of every sizeof() to an int before comparing, is there anything
>> simpler I can do, e.g. set a compiler flag or #define?
>>
>> Thanks,
>> Hamish
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
--
Clark S. Cox III
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden