Linked by Eugenia Loli on Mon 10th Oct 2005 16:48 UTC, submitted by Shlomi Fish
Thread beginning with comment 43041
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
:: I agree with you that the Freecell Solver coverage is a weak point of the essay.
Very weak indeed, first you go talking about portability... and the first thing one finds when downloading the source is autoconf... you dismiss you own point.
And then, autoconf is not enough... for instance it does not build out of the tarball on MacOS. Very simple to fix but still weakens even more the portability argument. Why does not it build? Simple enough, while claiming that C code is portable because there exists the ANSI C spec... you go and do:
# include <malloc.h>
Which is not part of ANSI C. Dear sir, malloc's() prototype is part of <stdlib.h>.
Not only that but all you header files are guarded by macros that start with a double underscore... but all such identifiers are reserved and should not be used by programs (see section 7.1.3 of the spec.) Another portability problem since those identifiers belong to the compiler, not to you.