Please, just forget this supercilious attitude...
It might sound a bit facetious, but there is a difference between knowing 'something about 2s complement' (or perhaps having heard about mul vs imul etc), and actually understanding the subject in all relevant details.
But the answer is no, I'm only sure that you deliberately miss the point and have a tendency of completely ignoring parts of posts that do not confirm your claims.
That's one way to look at it...
However, I don't think I have made any claims. I merely stated that you'd have to be doing some pretty funky pointer arithmetic for the 2 GB vs 4 GB to be an issue.
Addition, subtraction and multiplies are not affected, as we've covered so far.
Comparisons and divisions may or may not be affected, but only in specific cases, where the first mistake is to use signed integers for pointers, which counts as very 'funky' pointer arithmetic in my book.
So is it also true that there is no case where div vs idiv makes a difference in pointer arithmetic?
No, but I never claimed otherwise.
In theory there are certainly cases where div vs idiv could matter.
However, I can't really think of any practical cases, since the issue is mainly when you divide pointers directly.
I can't think of any useful application of doing so.
In practice you would usually calculate an offset first, by taking the difference of two pointers.
However, that difference in 2s complement is not going to be affected by signed or unsignedness of any variables.
Any resulting divisions would only fail if that offset is larger than 2 GB. But is that even a practical situation? In the case where your entire process only has 2 GB, it is impossible to get such an offset in the first place, so your program would have failed anyway, if you needed more than 2 GB of memory.
And in the case where you enable the 4 GB flag, as long as the actual data stays below 2 GB, the offsets will not wraparound, and again you should not get affected.
But there is this 'uncanny valley' here... What kind of programmer would be smart enough to go and try to do super-fancy arithmetic with dividing pointers and whatnot, yet is clueless enough to not use unsigned datatypes?
I think that is a pretty rare combination. Most programmers are either too scared or ignorant of pointer arithmetic to even try, and compilers won't generate code that breaks. And (presumably) most programmers who are actually knowledgeable enough to do their own pointer arithmetic, will know what datatypes to use.
But the whole conversation was about : Can there be situations/programs where 2GB+ pointers can cause problems? I claim yes.
And I agree there.
The fact is there are 32-bit programs/libraries/drivers that have problems with 2GB+ pointers. They exist.
Certainly. In fact, the whole reason why PAE was never enabled on desktop versions of Windows was because of all the poorly written drivers that would break.
Then again, with drivers you would be more likely to perform all sorts of low-level operations, and pointer arithmetic would be more likely than in most applications and libraries. Heck, entire applications and libraries are written in languages that don't even support pointer arithmetic in the first place. There is an entire generation of programmers today that doesn't even know what pointers are.
That's not a counter argument that it's only because of bad programmers.
It wasn't meant as one. Bad programmers do exist. In fact, "pointer arithmetic" is one of the points I have listed as things that separate the men from the boys when it comes to programming.
Heck, at work a few years ago, I saw a bunch of code that was made '64-bit compliant' by casting all pointers to 64-bit integers, regardless of the target platform. So yes, even poor 32-bit x86 CPUs would have to process the pointer arithmetic in 64-bit.
Okay, that 'solution' kinda sorta worked, but clearly the guy that did this had absolutely no clue what he was doing (and the code would just as easily break again for any architecture with pointers of more than 64-bits... The problem wasn't solved, merely moved around).