@CopperheadSec @ch3root But its not. The rules about integer to pointer conversions and uintptr_t are not respected by this.
@ch3root @CopperheadSec My view is that == operator is insufficient to establish identity; this is only way I see to reconcile with annex J.
-
-
@RichFelker@CopperheadSec So, you are saying that you cannot use (int *)(void *)p instead of p. Great!:-) -
@RichFelker@CopperheadSec Seriously though, this is probably a small bug in the C std and can be fixed.
End of conversation
New conversation -
-
-
@ch3root@CopperheadSec OTOH if reprs (or int values, "pure binary") are observed identical I don't see any way 2 justify "tracking history" -
@RichFelker@CopperheadSec Yeah, this is the real problem. a + 20 and b have the same repr. Can be used interchangably? -
@ch3root@CopperheadSec If program never inspects repr I see potential justification for treating them as different. -
@ch3root@CopperheadSec But if same reprs are observed I see no way the impl can treat them as not the same. -
@RichFelker@CopperheadSec So the example which started this discussion is fine with you? -
@ch3root@CopperheadSec For a weird definition of "fine". I see a plausible way to justify it & the code as written is "morally wrong" C. ;) -
@RichFelker@CopperheadSec If you allow it then I guess you cannot optimize all similar cases when iter count is unknown. -
@RichFelker@CopperheadSec A compiler has to assume that the loop could touch all variables following the original array.
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.