Anyone want to guess what gcc generates for a==b?0:a-b ? Any ideas why?
-
-
Oh, fun. gcc <= 7 gets it right too. Only gcc 8 fails to collapse it. I wonder if this is new logic to prevent wrongly applying "pointer provenance" stuff to pointers cast to integers.
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Under what condition would (void*)a - (void*)a not equal (intptr_t)a - (intptr_t)a == 0? NULL is just (void*)0 on any platform in use today (or, ever, I think) so I don't understand how it could pose a problem.
-
Difference of void* pointers is not defined at all. Difference of pointers to complete types is defined only when they both point to elements of the same array. The null pointer does not point to the element of any array, so differences involving it are undefined.
-
The point of this whole line of investigation is to be able to write a-b efficiently in a form that's defined given that one of the following is true: either a and b both point to elements of the same array, or they're both null pointers.
-
Really, failure of C to define a-b when both a and b are null pointers is a defect IMO. The right resolution is probably for someone to write a defect report and get it accepted.
@jfbastien?@gustedt? -
It would be a new feature, not a defect. Including this would have to be well argued. Do you know what C++ does, here?
-
If all existing implementations work this way (null-null==0) it seems like an oversight that it wasn't specified to begin with. BTW a related issue is that relational operators should be defined on null,null (false for <,>; true for <=,>=).
-
I wouldn't be sure that all implementations do this. There are still implementations that have several representations for null pointers. Your idea would put the strain of doing a case analysis on all code that does pointer subtraction.
- 1 more reply
New conversation -
-
-
(ptrdiff_t)((uintptr_t)a - (uintptr_t)b) generates the assembly code that you expect.
-
This is only convenient for pointers to char types, and it makes assumptions about the representation of pointers, but I think that musl is making these assumptions elsewhere already.
-
Yes, but I like to compartmentalize assumptions like this. This isn't documented well now, but there shouldn't be a reason that stdio can't be reused unmodified on a system with different address space model & pointer representation.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.