Dave,
I made at least one change you suggested:
#include <stdio.h>
void f(char *buf) {
unsigned int len = 0xFFFFFF00u;
if (buf+len < buf) puts("true");
}
int main(void) {
char buffer[100];
printf("buffer addr = %p.\n", buffer);
f(buffer);
return 0;
}
And compiled with flags:
/O2 /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE"
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /nologo /c /Wp64
/Zi /TC /errorReport:prompt
The output of this program is:
buffer addr = 0012FF18.
true
The reason the len is so high is to force an overflow when added to
0x0012FF18.
BTW, I also tried compiling this as a C++ program under visual studio
and got the same result.
rCs
Robert C. Seacord wrote on :
Specifically with regards to MSVC 2005, I thought Chad had already
checked this and found that it did not exhibit this behavior. I just
tested the following program.
#include <stdio.h>
void f(char *buf) {
unsigned int len = len = 0xFFFFFF00;
I'm sure you didn't mean to do that, but I doubt it affects the results.
BTW, that's a very different number from (1 << 30). How about trying again
with a 'u' suffix? Or with something that doesn't have the sign bit set?
cheers,
DaveK
