ANSI-fied headers for gcc

[Ronald Guilmette]

In article <17794 at duke.cs.duke.edu> crm at romeo.cs.duke.edu (Charlie Martin) writes:
>Can anyone point me to the appropriate place for ANSI-conformant .h
>files for Suns, or tell me the canonical way in which to use gcc on
>Suns with the existing header files?

(Advice on generating "better" include files for various systems is given
below.  But first you must suffer through my tirade! :-)

The whole situation with regard to "system" include files seems a bit
muddled at the moment.

Whenever the GNU C library becomes available, it is my understanding that
it will come with a set of include files of its own.  I can only hope that
these will be tested with g++ (and with cfront) and that they will be
compatible with those.  (I'm willing to help test for compatability when
the time comes.)

Also, one must assume that when there is a GNU kernel, that *it* will
also come with its own include files.  Again, I hope that these will be
provided in a form that is compatible with gcc, g++ and cfront.

For both of the above groups of GNU include files, the question which
looms large is: Will these include files contain function prototypes?
If so, then they may be compatible with C++ language processors, but
they may break non-GNU C compilers.  If not, then using any sort of C++
language processor with other GNU stuff (i.e. kernel & C library) will
be quite impossible.  Either way, *some* combination of stuff will not
work.

Another complication is the set of include files now provided with libg++.
Will these be merged (somehow) with the other two sets of GNU include files
mentioned above?  I (for one) don't know the answer to that question
(but I would very much like to).

Yet more complications arise during this interm period while we are all
waiting for the GNU C library and the GNU kernel to arrive.  (And for
those people who will not be able to go pure-GNU for political reasons,
these problems will persist even after the GNU kernel and C library
arrive).  In particular, the question arises: How can I use my brand X
computer (with my brand X kernel and C library) right now and still be
able to use gcc and g++?

Well, for gcc, there is a special script called "fixincludes" that tries
to help you workaround certain known instances of non-standard (or just
plain wrong) usage in *some* include files for *some* popular systems
(most notably Sun).  Unfortunately, fixincludes is only a stopgap
solution (and not a very robust one).  It certainly doesn't claim to
fix *all* the problems in *all* the system include files for *all* of the
hardware and *all* of the operating system revision levels that GCC now
runs on.  To get it to handle *all* of these cases would take several
man years.  Even if it did handle all these cases flawlessly, fixincludes
makes no attempt to introduce function prototypes (needed for C++ compatability
and generally useful anyway) into the "fixed" system include files.  It is
thus a rather minor tool, lacking some of the more important aspects of
functionality that such a tool would (in an ideal universe) have.

For g++, there is a whole slew of out-and-out *replacement* system include
files which completely override many (but not all) system include files
for many (but not all) popular machines.  Keeping these compatible with
zillions of different possible g++ host/target systems is (I'm sure) keeping
Doug Lea very busy.  As g++ (and libg++) gain popularity, I keep expecting
to read on net news that D.L. has been found dead of exhaustion at his
worstation while making one last compatability hack to the libg++ include
files. :-)  As with fixincludes, there is no way that Doug can possibly
keep up with *all* of the machines and OS revision levels that gcc, g++, and
libg++ are being ported to.

I am not even going to dwell on the *additional* compilcations that arise for
people who want to use both g++ and AT&T's cfront on the same system, other
than to note that cfront also comes with *its* own (different) set of
semi-replacement include files.

So what is a poor user to do?

Well, if we get a GNU kernel and a GNU C library (and if we can all convince
our local managements to use them) then we will probably be home free (if we
can assume that the relevant include files will be "fixed" and prototyped and
compatible with both ANSI C and C++).

Until then, you can use fixincludes to solve part of the problem (i.e. the
out-and-out non-ANSI'isms) on *some* systems.  Solving the prototypes problem
is a bit harder but still doable.

If I get time, I plan to create a heavily modified version of fixincludes
which can invoke my protoize program to automatically add *all* needed
function prototypes to known sets of "native" system include files for
various popular systems.  You can do this yourself right now by making
clever use of "source" lint libraries.  I can provide more details to
interested parties via E-mail.

Once my "protoizing fixincludes" exists, I assume that the gcc-include
directory will tend to fill up quite a bit more than it now does with
replacement (i.e. "fixed") include files.  Probably, you will end up
with fixed (and protoized) versions of almost all of your native
include files.  This will be a great boon for C++ programmers who are
currently unable to make use of tons of system-specific features
(like for instance neat parallel stuff on Sequents) simply because
the native system include files don't have the prototypes needed to be
compatible with C++.

Anyway, I'm concerned about the include file issue because it seems to
be an area where everybody is off doing their own thing (especially
the computer system manufacturers, most of whom don't even bother to
get ANSI-C compatible).  There appears to be neither concensus nor
coordination.  I can only hope that people will begin to realize
the truth of that old maxim: "No include files is an island."


// Ron Guilmette (rfg at ics.uci.edu)
// C++ Entomologist
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.