error: ordered comparison of pointer with null pointer [-Werror=extra]

Question

I am getting the below error in linux arm architecture when trying to compare void pointer addr>(void *)0XFFFE00000000 .Here addr is of type void pointer error: ordered comparison of pointer with null pointer [-Werror=extra]

This is happening only in Linux arm architecture,in other architecture it is working fine

addr>(void *)0XFFFE00000000

How to solve this?

@OznOg question is how to solve this as my code has compiled in all other platforms except linux arm hf — scx, Jun 12 '19 at 19:20
@OznOg addr>(void *)0XFFFE00000000 this is the one line code — scx, Jun 12 '19 at 19:26
well then give more context, what is addr, and where is the `;` ? — OznOg, Jun 12 '19 at 19:27
@OznOg address is si_addr of a signal https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp and the code is if(addr>(void *)0XFFFE00000000 ) — scx, Jun 12 '19 at 19:38
Comparing pointers for ordering doesn’t make any sense except when both pointers point into the same array (and even then it’s questionable at best). The ARM compiler is right to reject the code, and ideally other compilers would *also* reject it. The fix is to use equality comparison instead of less-than. — Konrad Rudolph, Jun 12 '19 at 20:15
The problem here is my signal's address higher bytes is getting overwritten by 0XFFFE0 ,so I thought to check if the address is greater than this value,I will remove this offset,can you suggest how can I use equality comparison in my case — scx, Jun 13 '19 at 03:51
@srinicx I’m still not sure what you mean but would this solve it? `if ((((uintptr_t) addr) & mask) == mask) addr = (your_type *) (((uintptr_t) addr) & ~ mask);` where `mask = 0xFFFE00000000`. — Konrad Rudolph, Jun 13 '19 at 09:45
@KonradRudolph In the working scenario, addr=0x12ab840 and in the non working scenario addr=0xfffe012ab840 , I am working on to remove first 20 bits of the address i.e 0XFFFE0 if and only if the address is greater than 0XFFFE0000000 — scx, Jun 13 '19 at 11:26
@srinicx Yes, that is exactly what my previous comment does. — Konrad Rudolph, Jun 13 '19 at 12:59
@KonradRudolph uintptr_t mask=0XFFFE00000000; if(((uintptr_t)addr & mask) == mask && uid==0) { addr=(void *)((uintptr_t)addr & ~mask); } I used the code suggested by you but it fails in 32 bit machine as the size of void pointer(uintptr_t )is 32 bits,can I dynamically assign the mask based on bitness, for now I have defined conditional compilation for 64 bit #if UINTPTR_MAX==0XFFFFFFFFFFFFFFFFULL #define Build64 1 #endif — scx, Jun 14 '19 at 16:35
@KonradRudolph Any thoughts on this how to make generic independent of bitness? — scx, Jun 21 '19 at 08:42
@KonradRudolphThe below code suggested by you does not left shift in 32 bits,so mask will be 0XFFFE. The problem is my address is 28-32 bits and for 32 bit if the lower two bytes of the address is 0XFFFE ,it would hit the if condition and mask the address which would again cause the issue. To be more clear about my issue,the offset is not happening in 32 bits ,and issue is happening in 64 bits randomly when higher 16 bits of the address is getting overwritten. Better approach would be to include macro for 64 bit,however I am not allowed to do so as the code has to be common for 32bit &64 bit — scx, Jun 23 '19 at 12:47

score 1 · Accepted Answer · answered Jun 12 '19 at 19:51

Probably the integer literal is overflowing into 32 bits, which becomes 0 or NULL.

But you shouldn't go around comparing random (void) pointers for being greater than some random integer, anyway. Cast the pointer to uintptr_t, and make sure the literal is of a suitable type too, then it starts becoming more likely to work. There doesn't seem to be a UINTPTR_C() macro, but perhaps it makes sense to use UINTMAX_C()?

Of course, if your unspecified "ARM" is 32-bit, then the address is way out of bounds and probably larger than the pointers will be ... quite confusing.

Why I am checking this random address can be attributed to this question :https://stackoverflow.com/questions/56406841/while-return-si-addr-with-offset-from-sigwaitinfo-function-causing-segmentation?noredirect=1#comment99714415_56406841 — scx, Jun 12 '19 at 20:04

score 0 · Answer 2 · answered Jun 21 '19 at 09:31

Comparing the ordering of two pointers doesn’t make sense except when both pointers point into the same array (and even then it’s questionable at best; generally you’d use inequality instead of ordering).

Since your actual problem is

my signal's address higher bytes is getting overwritten by 0XFFFE0

The first order of business is to find out why this is happening and whether it can be prevented: If an address gets overridden this indicates that there’s something very wrong with the code, and that you should fix the root cause rather than the symptoms.

That said, if all that’s required is to zero out the higher, overridden bytes of your pointer, the portable way is to convert the pointer to an integer and manipulate that, rather than manipulating the pointer directly:

const uintptr_t mask_bytes = 0xFFFE;
const int mask_width = 4 * CHAR_BIT; // ?!
const uintptr_t mask = mask_bytes << ((sizeof(uintptr_t) * CHAR_BIT) - mask_width);

uintptr_t uaddr = (uintptr_t) addr;

if ((uaddr & mask) == mask) {
    addr = (void*) (uaddr & ~ mask);
}

… substitute void* with your actual pointer type.

I have asked my actual issue in other question why the signal is getting offset https://stackoverflow.com/questions/56406841/while-return-si-addr-with-offset-from-sigwaitinfo-function-causing-segmentation — scx, Jun 22 '19 at 12:11
The above code suggested by you does not left shift in 32 bits,so mask will be 0XFFFE. The problem is my address is 28-32 bits and for 32 bit if the lower two bytes of the address is 0XFFFE ,it would hit the if condition and mask the address which would again cause the issue. To be more clear about my issue,the offset is not happening in 32 bits ,and issue is happening in 64 bits randomly when higher 16 bits of the address is getting overwritten. Better approach would be to include macro for 64 bit,however I am not allowed to do so as the code has to be common for 32bit &64 bit — scx, Jun 23 '19 at 12:46
The user ID of the signal is changing to nobody(65534) hence the offset 0XFFFE — scx, Jun 24 '19 at 12:41

error: ordered comparison of pointer with null pointer [-Werror=extra]

2 Answers2