[IPOL discuss] comments needed : [draft] IPOL Software Guidelines v.1

eml enric.meinhardt at cmla.ens-cachan.fr
Tue Nov 8 12:17:18 CET 2011


I have a few comments and questions on the software guidelines.

Section PORTABILITY:  How realistic is it to exclude POSIX?  I see
that windows is certified posix compliant (as opposed to linux).   I
understand that this compliance can be enabled by downloading a free
update from microsoft webpage:
http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=274
, and this  is included (but not enabled by default) in windows vista:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23754
 For anyone with windows experience: is that true?  Can I really use
posix calls on windows? If that is the case, then all the world is
effectively POSIX, and we can safely allow its useful capabilities in
IPOL.

Section COMPILATION:  This section seems POSIX-specific (because of
the compiler options).  Does it clash with the previous exclusion of
posix?

Section PORTABILITY: This section seems to say (although it does not
really say) that IPOL programs will compile on standard environments
of linux, mac and windows.  This is far from true.  For example, any
C99 program will not be compiled by Visual C.

Section COMPUTING RESOURCES: Please, say how much stack space will be
available to the algorithm (so that programs can enable protection for
recursive functions and variable-length arrays).

Section SOURCE CODE QUALITY:

1. Why 79 and not 80 characters?
2. I agree strongly to forbid white space at the end of lines and
enforce correct indentation.  This is like asking english text to be
free of typos (text with typos conveys the same message, but looks
weird and not serious to many people: the same thing happens with
incorrectly formatted code).
3. If disallowing CR+LF terminations is too strong a requirement,
mixed files (some lines ending in newline, some in CRLF) should be
disallowed.
4. 1000 lines per file is probably too few for people who prefer a
literate programming style, where the whole main function is written
in a single file with intertwined comments


Section LICENSE: Why is not the AGPL license included?  This licence
is very relevant for IPOL, since it forces that all "remotely
executable" copies of the software provide a means to get the source
code.  With classical GPL and BSD licenses, somebody could run a
mirror of IPOL with some modified algorithms and not publish their
source code.  Authors who are worried by this problem could choose the
AGPL.


Section SOURCE CODE DOCUMENTATION:
1. How do we link from the source code to the mathematical description
2. The requirement that all functions must have a comment rules out
self-documenting code.  This looks ridiculous to me:

// sum two vectors
void sum_two_vectors(float *out, float *in1, float *in2, int n)
{
...
}

In that case, I would say that the comment is distracting and thus, incorrect.

Annexes:
There should be a direct link to the axpb.tar.gz template program (or
to a similar template).


More information about the discuss mailing list