The Pathfinder code heavily depends on many many C99'isms, and we all agree that the use of C99 features makes the code much more readable and---most importantly---less prone to errors.
The patch that Fabian distributed here only removes a tiny part of the C99 dependency, namely variable declarations within `for (...)' clauses. I think this specific part of C99 dependence has never been a concern in our project. These are rather straightforward to remove (as Fabian did), but also never really made any trouble during compilation.
What makes our code really C99 dependent are mainly variable initializers in our code. We have plenty of situations where we do
type varname[] = { [pos1] = value1, [pos2] = value2, ... }; This seems like a poor programming style to me, because it leaves elements un-initialized. A major source of errors. I tend to adhire to the scheme 'always initialize upon declaration and also finalization'. (e.g. in M5 I spent quite some effort to remove/reinitialize everything upon closing the system to ease detection of errors. In M4 we mark released memory for the same purpose).
or
struct foo = (foo) { .bar = v1, .baz = v2 };
etc.
*These* are the situations where we need the C99 dependency. And these are also the situations where we *don't* want to rewrite our code to ANSI C. The availability of these language features are quite crucial to the style we program in Pathfinder. Removing them would make our code *very* fragile, as we would suddenly depend on the *order* in Please explain the fragility aspect to me. Also the order aspect is unclear. As far as I recall it is just a textual shorthand for a declaration directly followed by an initialization. which, e.g., bindings occur in an array.
I don't have any real problems with the patch Fabian provided. It is a matter of taste where one prefers to declare variables. The path does *not*, however, remove our dependency on C99 features.
@Fabian: What is the reason that you don't want to have the -std=c99 flag in your next ebuild? The compilers available for Linux provide excellent C99 support. Only the ignorance of Microsoft in their compiler suite makes the use of C99 appear a bad thing. The impact on portability should be documented. And perhaps a conclusion should be taken that MonetDB/* ceases to be supported on some. It is then a conscious decision on what community you want your
Dear Jens, Thank you for the contribution, because it sheds a better light on the rationale behind choices. It also shows the personal value attached to the issues using a strong tone of voice. Finding a solution is a matter of analysis of the real problems and the effort required by someone to adjust the/his work, or to recognize that some results are not achievable. I respect the coding style, but also would like to understand the ratio for them. So a complete list of C99 dependencies is as important as to see where/how this affect the config/compilation schemes. Jens Teubner wrote: products to be taken up.
Regards,
Jens
P.S.: I'm not yet through with a successful native compile of Pathfinder on Windows using the Intel compiler. It seems like also the Intel compiler has some problems with variable initializers, but only if they get a bit more complex (we had this on the Linux side some time ago, icc v7 or so). This seems to only affect two or three situations in our code, and we were already discussing solutions to this here in Garching.