GUYS! This time it's not for me I SWEAR. Arthur K. asked me to make this question because he didn't have the time. I know the answer but I'm going to make the question anyway. 
So, Arthur is working on a videogame and he is trying to support Linux, but he founds out that when he was trying to compile his game on Linux he was getting a lot of bugs, normally related to unitialized pointers.
The thing is that on Windows it seems that those unitialized pointers are not causing any problem, and that seems to be making Arthur get really mad. So he was wondering if it's related to a flag that need to be set on the compiler or maybe because on Windows he's using GCC 4.8.1 and on Linux (Ubuntu 12.04) he's using GCC 4.6.3?
He told me that he's using Code::Blocks and both Windows and Linux are set to compile on release mode, not debug, so let's see if we can help Arthur. What could be the problem?
Edit:
Disclaimer: Arthur K. didn't actually told me to make this thread, it was just me trying to be "funny".
Compile with warnings enabled, fix the warnings about uninitialized variables 
Oh, I told him that, and he told me that he was already using those flags. But he told me that on Windows some unitilized pointer weren't crashing the entire application while on Linux the program was "Segmentation Fault".
Is he using -W -Wall, -Wextra ?
Which Windows? XP? Vista? 7? 8?
When I made the switch from XP to 8, I immediately started getting crashes with my current project whenever I quit, except for in very specific circumstances. When I started work on my project again, I traced the problem to Allegro objects which were getting uninitialized twice, the first time while Allegro was still running, the second time after Allegro was shutdown, yet even though the objects were NULL the Allegro object destroying routines were still being run. On XP, this did not generate run-time errors, but on 8 this did.
My point is that if you're not running into problems on an older version of Windows, yet are running into problems on Linux, you might trying going up to a later version of Windows and see if those problems present themselves.
As for good coding practice, I always, always, ALWAYS initialize pointers to NULL when they're first created, even if I'm about to store data inside of them, and when I use an al_destroy routine on one, I always, always ALWAYS set the pointer to NULL immediately following as a separate command on the same line. There's about a million problems you can avoid by ensuring pointers are always NULL when they're not doing anything.
Because they are initialized to different (random or not) values on different platforms, with different compilers, etc. In one case they might point to memory that happens to be owned by that process, in another case not. The OS will only kill the process in the latter case, not in the former case. But the process will often mess itself up pretty badly, and might crash or behave in weird ways. Or the pointer might be NULL, which triggers an exception in the CPU if you try to dereference it. The CPU informs the OS, which handles the matter by nuking the offending process.
Why is he using uninitialized pointers anyway? If he wants to know what is going on, he could just print the pointer values.
I's also the case that windows, and especially older versions of windows had much less severe memory management and error detection than Linux. In other words, the program was already bug-ridden. Linux just brough the problem to the light where windows ignored those bugs. If you use valgrind on Linux you'll have these problems traced and solved down pretty quickly.
Is he using -W -Wall, -Wextra ?
Let me ask him... Yes he's using those flags.
Which Windows? XP? Vista? 7? 8?
Windows 7.
When I made the switch from XP to 8, I immediately started getting crashes with my current project whenever I quit, except for in very specific circumstances.
What, really? 
Even between Windows versions? I must tell him that immediately. Yes I'll tell him to start "nulling" the pointers, he was just prototyping and all that.
Because they are initialized to different (random or not) values on different platforms, with different compilers, etc. In one case they might point to memory that happens to be owned by that process, in another case not. The OS will only kill the process in the latter case, not in the former case. But the process will often mess itself up pretty badly, and might crash or behave in weird ways. Or the pointer might be NULL, which triggers an exception in the CPU if you try to dereference it. The CPU informs the OS, which handles the matter by nuking the offending process.
Oh you hit the nail on the head.
Why is he using uninitialized pointers anyway? If he wants to know what is going on, he could just print the pointer values.
No no wait, we may not be understanding what Arthur is trying to say. Pointers were already initialized but like in every program there is a moment in which you have to destroy the object/whatever the pointer is pointing to, the thing is that on Windows after destroying the object and trying to access one of the values of that object was not throwing any segmentation fault, while on Linux this was happening immediately. It was an easy error, Arthur just was worried about why this behavior. But he pretty much understand it now.
If you use valgrind on Linux you'll have these problems traced and solved down pretty quickly.
Oh I'll che... I mean, I'll tell him to check that program. Thanks Everybody!
If you use valgrind on Linux you'll have these problems traced and solved down pretty quickly.
Beat me to it. Problems like the one described practically scream valgrind.
In the future, it would be a good idea to test with valgrind periodically... It's like going to the dentist: You can wait until you've got a big, hankering cavity and it hurts to chew--or you can go periodically and nip problems in the bud. The former results in not only more pain but a bigger bill as well.