Typecast from negative integer literal to a pointer returns NULL. If doing the same with an integer variable, typecast is done OK.
Experienced on Z80 port.
Fixed in revision #8120
Philipp Klaus Krause
While adding a regression test for this in revision #8121, I noticed the bug is still there for mcs51 and ds390.
No, the new regression test is illuminating a different problem: If the pointer type is larger than the signed integer type, the upper bits of the resulting pointer are computed differently between the literal and non-literal cases. The literal case is handled analogously to how a signed int is converted to a (un)signed long, with the sign bit extended into the new bits. The non-literal case assigns a value of 0x40 to the upper byte of the resulting pointer. So the regression test fails because 0xffffff != 0x40ffff (before #8120 it would have failed because 0x000000 != 0x40ffff).
I'm not finding any guidance in the C standard on how casting from an int to a larger pointer should work. The handling of the literal case seems more reasonable to me, so my inclination is to change the code generator to match this behavior with the non-literal case. Or are there any reasons we should handle this another way?
The value 0x40 is wrong and should not be applied. It is the indicator for the memory space where i lives (data), not where the pointer might point to. For the large model it currently uses 0x00 (xdata) and for medium 0x60 (pdata). I agree the literal case is best and should also be applied to the non-literal case.
Casting an integer to a pointer now works the same for literal and non-literals on mcs51 and ds390, so the regression test passes as of revision #8143.