On 27/03/2012 19:32, Tim Rentsch wrote:
> Francois Grieu <> writes:
>
>> I just tested my code for portability problems on systems
>> where int is 16-bit, and found one such system where
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> printf("%d\n", 0<(unsigned short)0x8000 );
>> return 0;
>> }
>>
>> outputs 0. If I change 0< to 0u<, the output is 1.
>>
>> Is that a bug in this compiler, w.r.t. C99?
>
> Yes. There is a simple argument that it is:
>
> 1. The value 0x8000 is always representable as an unsigned short.
>
> 2. The rules for 'integer promotions' always preserve value.
>
> 3. The rules for 'usual arithmetic conversions' preserve value
> for all operand values that are non-negative. (A negative
> operand value might become non-negative due to UAC, but
> all non-negative values don't change under UAC.)
>
> Since 0 < 0x8000 must hold, 0 < (unsigned short) 0x8000 must hold,
> because ultimately the same mathematical comparison is done.
Nice, reusable argument. Thanks.
>
>
>> As an aside, 6.5.8p2 puzzles me; [snip]
>>
>> As an aside of the aside, I do not understand the third option in
>> the constraint, and it has been removed in N1570.
>
> The removal is not a change but just indicative of a change in
> nomenclature. In C99, there are incomplete types and object
> types. In N1570, there are incomplete object types and complete
> object types, which together make up object types. So in N1570,
> both complete and incomplete types are included under the now
> more general 'object type' term, and hence the third option in
> C99 is folded into the second option in N1570.
Again, thanks for the synthetic explanation.
Francois Grieu
|
Similar Threads
