unsigned int 2 ulong type promotion issue in GCC!
Thamilarasu Kandasamy (thamil)
thamil@cisco.com
Tue May 26 03:32:03 GMT 2020
Hi
I could deduce what is happening based on the output of the program.
I am looking for an affirmative answer which explains because of this type promotion rule involving unsigned long and unsigned int, promotion of low rank type to high rank type doesn't happen, please quote that rule.
As per my understanding, type promotion from unsigned int to unsigned long int should have happened. But it doesn't, hence I am trying to know which type promotion rules apply here, is it documented anywhere ?
Thanks
Thamil
On 24/05/20, 7:21 PM, "Liu Hao" <lh_mouse@126.com> wrote:
在 2020/5/24 21:31, Thamilarasu Kandasamy (thamil) via Gcc-help 写道:
>
> int size = 100;
> unsigned int usize = 100;
>
> result1 = (void *) (((uintptr_t) &var) & ~(size - 1));
> result2 = (void *) (((uintptr_t) &var) & ~(usize - 1));
> result3 = (void *) (((uintptr_t) &var) & ~((unsigned long int)usize - 1));
>
`result1` is bitwise AND `&var` with `(uintptr_t)~(int)99` which is
`(uintptr_t)(int)-100` which is probably `0xFFFFFFFFFFFFFF9C` on a
64-bit machine.
`result2` is bitwise AND `&var` with `(uintptr_t)~(unsigned)99` which is
likely `(uintptr_t)(unsigned)4294967196` which is `0xFFFFFF9C` on a
64-bit machine. So higher half is truncated as expected.
`result3` is bitwise AND `&var` with `(uintptr_t)~(unsigned long)99`
which is probably `0xFFFFFFFFFFFFFF9C` on a 64-bit machine.
There is no bug.
--
Best regards,
LH_Mouse
More information about the Gcc-help
mailing list