twinaphex/genesis-next — comment on commit 62ee45296bd1e23ca9dede6461caa59d0d0f7357
File:  line 0
By ekeeke:

I already fixed all of the C89 incompatible stuff that were reported by -ansi in gcc, mostly C++ comments, inline keyword (which I now redefined in types.h if it is undefined, as well as M_PI) and unnamed struc/union fields in ssp16.c as you already reported (it is not even C99 compliant, I believe it's part of C11 extension).

If I add -pedantic-errors flag, I still got plenty of errors off course, some of them being valid but there is just too much mixed variable initialization everywhere, some of them fixable, other I added on purpose. For that matter, I verified that devkitppc would generate quite different asm code when the variables are all declared at the beginning of functions, with a lot of chained register stack savings that, I believe, are not very optimized on a pipelined CPU. For code clarity, I also prefer having variable being declared when they are used, so I'm still not sure if I really want to change all that code, just because Microsoft has no interest in providing a modern C compiler ;-)

I would feel that the right approach would rather be to improve the free devkit solution on X360 rather than relying and basically supporting Microsoft poor support to C (and isn't it illegal to compile stuff with MSVC devkit by the way ?). But that's another debate, and I understand you are more concerned about the end result.

What bothers me more, and keep me undecided whether doing the changes or not, is that indeed, the original code was pure ANSI C compatible (for better portability I guess) and it would indeed be logical to keep it that way. You probably have notice that the current code barely has anything to do with the original though, there are things left sure, but everything was more or less revamped by me, with sometime optimization in mind and I admit I never cared about old ANSI C compliance, C99 being modern C standard in my scope and supported by gcc anyway.