Gcc is doing the right thing. You can't blindly assume malloc() never fails. That is up there with assuming int is always 32-bit and painting yourself into a corner with unportable code.
I can almost guarantee that you will add more bugs to your code trying to 'recover' from a malloc failing than just letting your process crash, and hopefully get launched at a better time.
The /correct/ way to write a production code is to assume your program will crash at some point, and it should be able to recover from for example, out of sequence starting. Even if it's not malloc(), the scheduler might kill you for its own reasons.
What do you DO if malloc fails? Cry for help? Oh oops, "cry()" might need to allocate memory.
Also, I was writing code when int was 16 bits, and quite frankly, the size of int was never really a huge problem in porting code, and I ported a LOT of code. I found a lot more problems trying to find code that were trying to 'fix unfixable" errors, like IO errors.
