Why do you need a "ptrdiff_t" type, why isn't "size_t" sufficient?
This page is a much shorter summary than the article: http://www.gnu.org/software/libc/manual/html_node/Important-...
Also an important note: if you use special types like ptrdiff_t and size_t, you must not use the underlying native type printf specifiers when printing them. e.g. never print a ptrdiff_t using %ld, use the ptrdiff_t format specifier %td. (because some systems may say ptrdiff_t is long while others may say long long, and all your printf strings will then print compile time warnings.) Also see https://en.wikipedia.org/wiki/Printf_format_string#Length_fi...
Plus, the medium article is a complete copy/paste of this 2009 article: http://www.viva64.com/en/a/0050/ — looks like the account https://news.ycombinator.com/user?id=PVS-Studio is copying from viva64 and posting to medium for a lot of old articles.
I guess that is one way to write articles.
Seems legit unless someone's actually impersonating someone else. I don't quite understand why, if Karpov wrote the original article and is a Medium contributor, Vasiliev rather than Karpov should be doing the reposting. (You could imagine something like this: K is a senior technical guy at PVS-Studio, V is a more junior technical guy or is in the marketing department; in 2009 they thought it better to post things under K's name to get it out there, but now K wants only the more impressive articles under his name and lets V post the others. But this doesn't feel terribly plausible.)
size_t is an unsigned type - it is used to represent the sizes of objects in memory, which can never be negative.
Another funny thing I just discovered: You can't declare an array like "char somearray[SIZE_MAX]"; clang gives "error: array is too large (18446744073709551615 elements)". But you can use SIZE_MAX as an array index (although it gives a warning "array index -1 is past the end of the array"). Also, trying to declare an array like "char somearray[SIZE_MAX/8]" inside a simple main() just sends clang into 100% cpu...
For greater-than/smaller-than comparisons, I see the utility of working in the signed space though. I guess it all depends on expectations. If you have a pointer to the very last byte of a 2^32 address space (0xFFFF_FFFF), and subtract a pointer to the second byte from the start (0x0000_0001), you'll end up with a diff that should be "SIZE_MAX-2", but will be parsed as "-2" in the signed interpretation.
Yeah, true. I recalled there being separate instructions and then messed up my napkin math to check if it made a difference within the relevant range.
Yes, but if you're just storing the delta between two pointers and then adding/subtracting this diff to get from one to the other it will still work. Of course it will also work using size_t.
This would require keeping track of which one is bigger somewhere else unless you had enough room to store a sign. Seems like a pretty goofy way to go about it if you're going to the trouble of making a type specifically to hold a delta.
Practically, amd64 is already limited to more like 48 bits (4 levels of 9 bit pagetables describing 12 bit pages) of memory.
Nope. You assume the math is being done mod 2^32 or 2^64 and it just works weather you use signed or unsigned integers. Pro-tip: the hardware does the exact same bit operations for signed and unsigned addition and subtraction (except for carry/borrow which aren't part of the C standard anyway). integer overflow is undefined, but this behavior is AFAICT universal anyway. If it didn't behave this way then a difference would in fact need the extra bit.