No, that's a really bad idea. The guys in this thread are smart; listen to them.
It doesn't. If (32-bit) p=0x7fffffff, q=0x80000000 (same array), q-p is perfectly well-defined but (long)q-(long)p is not.
-
-
In linux that address range is allocated to the kernel, longs wrap around when you don't break the compiler, and unsigned long exists.
-
(1) No, varies by arch; 32-bit x86 kernel has 0xc0000000+ reserved. Some archs are 0x80000000+ resv'd. 32-bit on x86_64 kernel = no resv'd.
-
(2) It's not broken but whatever, (3) unsigned long works if you want to assume address model. This precludes all advanced, safe C impls.
-
I.e. ensuring your code will not work in a much-better, much-safer future, and actively opposing said future by increasing cost to switch.
End of conversation
New conversation -
-
-
P.S. posix requires one's complement. This has come up before. http://lists.uclibc.org/pipermail/busybox/2017-February/085201.html …
-
You mean twos complement, and it doesn't, but twos complement is not relevant here. All that's relevant is that it's undefined.
-
Ideal implementations are equivalent to gcc's (maybe-broken?) -ftrapv, i.e. catching overflows to reduce serious bugs down to DoS.
-
FWIW: I think ideally things should both define signed types as twos complement, and also maybe support explicit trap&saturate for types...
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.