[Monetdb-developers] [PATCH] Loop Lifted Pathfinder sources

Martin Kersten Martin.Kersten at cwi.nl
Thu Nov 2 09:11:26 CET 2006


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:

> 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
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.
> 




More information about the developers-list mailing list