The result you get with this trick is signed, while the result you get with sizeof is unsigned.
Edit: Just to clarify, what you get is ptrdiff_t instead of size_t. So if array size is greater than PTRDIFF_MAX, you get undefined behavior [1].
Edit: Just to clarify, what you get is ptrdiff_t instead of size_t. So if array size is greater than PTRDIFF_MAX, you get undefined behavior [1].
http://trust-in-soft.com/objects-larger-than-ptrdiff_max-byt...
The standard also has the idea of "implementation defined" behaviour, which is close to the definition above. "Undefined behaviour" is a trickier beast, since compilers can rightly assume undefined behaviour never occurs, and optimise accordingly.
These days, compilers quite often speculate on undefined behavior, generating code as if the undefined part cannot happen - the result is that your code is going to do stuff you pretty much can not know or expect.
Software is unreliable enough as it is due to problems beneath our notice. It seems reckless to avoid fixing problems that we do notice. Sure, you could argue that rare problems are rare and that users probably won't notice them --- this attitude is penny-wise and pound-foolish, because you can't meaningfully reason about a system that's only probably correct.
If it were really as likely as, say, the sun exploding that X happened then it would be of no use to expend time on X.
BUT very often people speaking about the probability of events given suspicious constraints. While a memory allocation might not fail in most situations it will fail often in some situations. And a one-in-a-million chance is almost guaranteed when there are millions of uses.
One in a million literally means that at ~100k requests a second it will happen once every 10 seconds.
Correctness is great in theory, but in practice it's a matter of what's important.
But the question is important in another context: language design. Why is this undefined behavior something that exists in the first place? Objects larger than PTRDIFF_MAX could just not be allowed! This avoids the problem and makes code easier to reason about, with pretty much no downside.
bug in java binary search
and showed a related search in the drop-down, 'programming pearls ...', a book by Jon Bentley, which seems to confirm what I said above (though I saw it in his other book, "Efficient Programs", IIRC - he might have mentioned the same issue in the Programming Pearls book too).
Edit: and the Wikipedia article confirms it too:
https://en.wikipedia.org/wiki/Binary_search_algorithm#Implem...
Assertion failed: (Distance > 0 && "The distance must be non-zero"),
function areStridedAccessesIndependent, file /wrkdirs/usr/ports/devel/
llvm38/work/llvm-3.8.0.src/lib/Analysis/LoopAccessAnalysis.cpp, line 1004.
Let this be a lesson: Asserting that impossible things don't happen makes debugging much easier when they do happen!