On Wed, Nov 12, 2014 at 1:15 AM, Kamil Rytarowski <n...@gmx.com> wrote: > From David Holland >> Please don't do that. Nothing good can come of it - you are asking for >> a thousand weird problems where undisclosed ordering dependencies >> silently manifest as strange bugs.
Everyone is aware of that. Code conversion must be done extremely carefully. Order must be preserved. >> Furthermore, the compiler can and probably will assume that >> constructor functions get called before all non-constructor code, and >> owing to unavoidable issues in early initialization this will not be >> the case in some contexts. (I first hit this problem back in about >> 1995ish when some more gung-ho colleagues were trying to use C++ >> global constructors in a C++ kernel, and we eventually had to declare >> a moratorium on all global constructors.) Thanks, but irrelevant for kernel... >> init_main.c could use some tidying, but there's nothing fundamentally >> wrong with it that will be improved by adding a lot of implicit magic >> that doesn't do what the average passerby expects. Function pointers are not magic. (snip) > And last but not least... what's wrong with init_main.c? It must be clear for > a developer adding a new platform or debugging hardware bring-up. It gives me > big picture on that what's going on step-by-step, even when I was lurking > into assembly of our kernel... call it, call that, call this.. making it all > clear. Those functions are hardcoded and ordered even without dependencies among them, that's a big problem. The biggest problem of constructors (and indirect function call in general), I am aware of, is, static code analysis (code reading, tag jump, ...) becomes difficult (or impossible).