RE: building gmp-3.1.1 on darwin...

[Hans Aberg]

At 17:33 -0400 2001/08/04, David T. Ashley wrote:
>The serious point is that the GMP MP library is technically outstanding but
>does not meet universally accepted coding standards for the C programming
>language.

I will just give my own personal impressions (as a user, I am myself not a
part of the GMP project):

>a)The use of TAB characters, which is discouraged in over 1/2 of coding
>standards.

I have used a number of variations over the last years: UNIX systems always
sets tabs to 8 spaces, it seems, but on MacOS, I have used 4. On UNIX
systems, some use hybrids, every second a tab equivalent to 8 spaces, and
every second four spaces, as to emulated tabs on 4 spaces. This screws up
platform porting.

So eventually, I ended up with just using two spaces instead of a tab,
which is easy enough to type by hand. For readability, one does not need
more than two spaces on each tab, it turns out. Others seem to use this
too, for example the GNU Bison project.

>b)The inconsistent naming conventions, which could lead to a name clash if
>the source code is used in a larger project.

I noticed some inconsistencies in the OO that if changed could bring it
closer to the C++ class OO model. I would have preferred the name of each
file to be unique, because my compiler scans the whole sub-directory tree.

As for the names themselves, I use them in a C++ namespace wrap, so then
name conflicts is not a problem.

What problems do you have in your mind here?

>c)The lack of documentation in the code.  It is spotty.  In some places, it
>is outstanding, but in other places it is lacking.

I think this is inevitable, as this kind of source code documentation takes
time, and people that write this kind of code tend to learn how to read the
code itself.

>d)The sheer number of source files involved.

I think this is a platform issue: For example, under MacOS pre-X, it was
preferable with a low number of files, as the disk operating system could
not handle well many small files (a hard disk sector could not have more
than one file). However, under UNIX, the file is a basic unit in an
entirely different way. So in fact, under MacOS X, which has Mach-kernel
based BSD, the old multi-component files are split into different files,
and the use of many files is encouraged (with respect to the file resource
components).

>f)The inconsistent trapping at the interfaces.  (As I ported the code, I had
>to add a great number of assert() statements to trap suspicious things at
>function interfaces.)

Would mind giving some examples?

  Hans Aberg