[tex-live] K&R C compilers.

Olaf Weber olaf@infovore.xs4all.nl
03 Jan 2003 18:15:02 +0100

Nelson H F Beebe writes:
> Olaf Weber <olaf@infovore.xs4all.nl> writes on 03 Jan 2003 12:57:46 +0100

>>> Does anyone know whether it would be feasible to assume that all the
>>> compilers used to compile TeX-live are ANSI C?  Or least that they
>>> support the following:

>>> - void
>>> - prototypes
>>> - stdarg.h (for variadic functions)

> Please call it Standard C, not ANSI C; the ISO Standard has replaced
> the ANSI one, and the C Standards committee recommends ``Standard C''
> as the informal designation of ``International ISO/IEC Standard
> 9899:1999(E),  Programming languages -- C''.

It's an easy mistake to make.  In fact, I'm quite willing to tolerate
substandard C as long as I can have (revised list):

- prototypes
- const
- void
- stddef.h
- stdarg.h

stddef.h is of interest as it is the "cheapest" header which defines
size_t and NULL.  But I could do without if needed.


> A lot of the Web2c code already has similar wrappers on function
> declarations and definitions.

But I'like want to avoid using those wrappers in the "new" public
kpathsea headers.

> However, if a decision is made to move TeXlive coding to Standard C,
> then the code should be made strictly C89 conformant, including correct
> prototypes of all user-defined functions,


> explicit declaration of all variables and functions (i.e., no
> assumed int types),

Agreed, implicit int turned out to be an abomination.

> proper conversion casts in function returns (e.g., malloc()),

That's not a C conformance issue.  (While C++ wants it, it can be
argued that this is bad C style, as it can hide errors.)

> and avoidance of C++ keywords as user-defined entities.

Assuming we know what those keywords are today.  :^)

> It will then be possible to compile it with C++ compilers too.  In
> every project where I've done this, C++ compilations have turned up
> insidious errors that C compilers on many different platforms,
> including non-UNIX ones like MS DOS, DEC TOPS-20, and DEC VAX VMS,
> never caught, so the effort has always been worthwhile.

The Omega project did this for web2c/kpathsea.  I don't recall if they
were able to turn up true errors this way, what I recall was the C++
keywords and (in C) lack of redundant casts issue.  Those bits should
be fixed now...

> The easiest way to check this is to compile the code under a strict
> C++ compiler (g++ is by default NOT strict, although it has objects to
> make it pickier).  The best one that I've found is SGI's CC.

I've access to that one.  (The Omega people I believe used g++.)

> As an experiment, I made a copy of the web2c-7.3.7 build tree on a
> local SGI system, and tried compilation with "make CC=CC -i".  Here is
> a sampling of the kind of errors reported:

> CC -DHAVE_CONFIG_H  -I. -I. -I.. -I./..   -g  -c tie.c
> cc-1312 CC: ERROR File = ../kpathsea/getopt.h, Line = 125
>   More than one instance of overloaded function "getopt" has "C" linkage.

>   extern KPSEDLL int getopt ();

That's a painful header...

> CC -g  -c ./alloca.c
> cc-1020 CC: ERROR File = ./alloca.c, Line = 171
>   The identifier "size" is undefined.

And that file is a known problem...for one thing it doesn't use the
"wrappers" at all...for another I'm not sure it is really required, so
perhaps it can be dropped in its entirety.

> This is not horribly bad: Perhaps only a few hours, or a day or two,
> would be needed to clean up the entire Web2C tree.  Tools like cproto
> and gcc's protoize can be used to help automate this job.

Olaf Weber

               (This space left blank for technical reasons.)