Question: This question HAS had to be asked before, so it kills me to ask it again, but I can't find it for all of my google and searching stackoverflow.

I'm porting a bunch of linux code to windows, and a good chunk of it makes the assumption that everything is automatically initialized to zero or null. 

```
int whatever;
char* something;

```

...and then immediately doing something that may leave 'something' null, and testing against 'something'

```
if(something == NULL)
{
.......
}

```

I would REALLY like not to have to go back throughout this code and say:

```
int whatever = 0;
char* something = NULL;

```

Even though that is the proper way to deal with it. It's just very time consuming.

Otherwise, I declare a variable, and it's initialized to something crazy if I don't set it myself.

Answer: 
No - there's no option to do that in MSVC.

Debug builds will initialize them with something else (0xcc I think), but not zero. Unfortunately, your code is bugged and needs fixed (of course this applies only to automatic variables -for statics and globals it's fine to assume they're zero initialized). I'm surprised there was any compiler that supported that behavior - if there's an option to do that in GCC, I haven't heard of it (but I'm no expert in the dusty corners of GCC).

You may hear that an earlier version of MSVC would init variables to zero in debug builds (similar to the way 0xcc is used in VS 2005), but as far as I know that's untrue.

edit ----------

Well, I'll be damned - GCC does (or did?) have the `-finit-local-zero` option. Looks like it's there mostly for Fortran support, I think.

I'd suggest using compiler warnings about using uninitialized variables to help you catch 99% of your problems. I know it's not a great bit of work, but it should be done if at all possible.
What I ended-up doing was switching to /w4. At this level, it caught most of the "yeah, that's going to be an issue" areas of initialization. Otherwise, there's nothing that can change everything from being 0xcccccccc on initialization to 0x00000000 that I saw.

Massive thanks to everyone for answering this, and yes, we will tighten it up in the future.