Re: unsigned int 2 ulong type promotion issue in GCC!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx> 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






[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux