0

I'm running cygwin on windows 10. I was messing around with some C++ and ran this code a bunch of times. My laptop turned unresponsive, and after a few seconds, I got a bluescreen and had to reboot. The thing is, all I'm doing is reading from memory and printing to stdout, which shouldn't cause this. I checked, and the array size doesn't exceed the max stack size for cygwin. 

#include <stdio.h>


int main (){
    double a[6675];
    int i = 0;
    while (i<6675){
        printf("%f\n", a[i]);
        ++i;
    }
return 0;
}
Jack M.
  • 9
  • The bluescreen does not violate the C++ standard, but it certainly does look like a bug somewhere. Though the standard doesn't define the behavior, there should be no bit pattern in a `double` object that would cause `printf` to blow up that way. (BTW, I can't reproduce the problem on my own Windows 10 system with Cygwin). – Keith Thompson Feb 09 '19 at 05:17

1 Answers1

2

It's undefined behaviour(1) and literally anything is allowed to happen, up to and including the early heat death of the universe.

Granted it's very unusual for the actual computer to blue-screen so you may want to consider the possibility that it's unrelated (unless you can replicate it of course).

But, as mentioned, don't do UB. There's a reason why the first word is "undefined" :-)

(1) As one example, floating point values are allowed to have trap bits, meaning that dereferencing arbitrary uninitialised variables may actually result in UB.

Short of trolling through the standard, there may be other cases where UB comes out of your given code. I just don't have the inclination to do that for code which should probably never see the light of day :-)

But, in any case, even if it weren't UB, it's still a bad idea, since you may well just print out a lot of arbitrary floating point values.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • Thanks! I've replicated it once, and my computer is pretty stable otherwise, so I'm pretty sure it's not unrelated. Yeah, I know it's undefined behaviour. Guess I'll just give up on trying to decipher why it happens and leave it at that. – Jack M. Feb 09 '19 at 05:01
  • I'm pretty sure this is UB as it is reading uninitialized local variables. – eesiraed Feb 09 '19 at 05:02
  • Also, yeah this is literally me messing with the compiler and seeing what it does with really dumb code, not intended for use in anything whatsoever. – Jack M. Feb 09 '19 at 05:03
  • 2
    Definitely UB, no doubt about it. `a` is an object with automatic storage duration, and therefore it has an indeterminate value unless and until it is initialized. Attempting to evaluate an indeterminate value is explicitly undefined behavior in both C++11 and later versions of the standard. (C++11 talks about it in terms of lvalue-to-rvalue conversions, if I remember correctly, which is particularly obtuse. C++14 made the wording much clearer. But the implication is identical in both cases.) That said, you're right that a modern protected-memory OS should *not* blue-screen here. – Cody Gray - on strike Feb 09 '19 at 05:06