How is it possible to have a buffer overrun on one platform but not another?

Question

I'm hesitant to ask this question because of the vagueness of the situation, but I'd like to understand how this is possible. I have a C++ application developed using Visual Studio 2008. When I compile the application on Windows 7 64-bit (or Vista 32-bit), the application runs fine. When I compile the application on 32-bit Windows XP SP3, I receive a buffer overrun warning and the process terminates. This is using the same verison of the Visual Studio 2008 C++ compiler. How is it that I receive a buffer overrun on XP, but not on other Windows platforms?

Answer 1

Write code so you don't have buffer overruns and you won't have this problem on any platform. Namely, make sure you check the bounds for the buffer you are accessing to make sure you aren't trying to read/write outside of the proper bounds.

Answer 2

Luck, the fundamental undeterminedness of the Universe, or (more likely than the previous) an implementation detail that changed in msvcrt.dll between XP and 7.

Bottom line is you have a bug in your application, and you should fix it.

Answer 3

You probably have a buffer overrun in both case, in the first it isn't detected and doesn't (apparently) do any harm. In the second it is detected. (If it is on a dynamically allocated memory, you have to know that allocators often allocate more than what asked, thus a plausible explanation is that in the first case the overrun stay in that zone, in the second it doesn't).

Answer 4

Sizes of data types might change from one compiler to another (thanks @AndreyT). Using hardcoded numbers like sizeof(4) to represent the size of a data type on your code, might pop up a bug on your application. You should use sizeof(int) instead or whatever type you are interested in.

Answer 5

Windows-7 has a feature called fault-tolerant-heap which ,as it says, is tolerant about some faulty buffer accesses. Windows XP doesn't have this feature (Vista ,I don't know). There is a video about it on channel9.msdn.com or sysinternal.com (forgot exactly where) by Mark Russinovich.