In message <[EMAIL PROTECTED]>,
Martin Cracauer <[EMAIL PROTECTED]> wrote:
>Others already said that replacing the system compiler will be
>difficult.
>
>However, you should be able to use any FreeBSD include file that is
>supposed to be used by userlevel code with any ANSI C conforming
>compiler. People like Bruce Evans once took great care to guarantee
>that. It seems this has gone under the wheel by less careful
>committers since around 3.0, but the goal is nontheless to keep this
>capability. If you have examples where it breaks, send them to me,
>please.
Well, if you are interested in doing some *serious* QA and ANSI/ISO
conformance testing on the system include files...
For hours of enjoyment, try running the following simple script:
-----------------------------------------------------------------------
#!/bin/csh
cd /usr/include
set hfiles=(`find * -follow \( -name g++ -prune \) -o \( -type f -name \*.h -print \)`)
cd /tmp
foreach hfile ($hfiles)
echo '------------------------------------------- Checking '$hfile
echo '#include <'$hfile'>' > includer.c
gcc -Wall -pedantic-errors -Wstrict-prototypes -c includer.c
end
-----------------------------------------------------------------------
NOTES:
[1] In an Ideal Universe, the above script should run to completion while
yielding ZERO errors and also ZERO warnings from the compiler.
[2] We do not live in an Ideal Universe.
[3] The ANSI C standard, at least, contains the requirement that each
individual system include file specified by that standard should
be usable all by itself, without the programmer being required to
explicitly include any OTHER system include files, prior to the one
he/she is actually interested in using. This is, I believe, a Good
Thing. However few are the systems where this sort of elegance
pervades ALL of the available system include files, which is a pity,
because if this `feature' were in fact pervasive, it would make QA'ing
the whole complete set of system include files much easier.
[4] Even if one does not accept the advisability of having each and
every system include file be ``includable'' all on its own, it
should, in theory, still be possible to work out a proper partial
ordering of the entire set of system include files, taking into
account which ones must be included before which other ones.
Using that partial order then, it should be trivially possible
to construct a single .c file which just includes each and every
one of the system include files in an order consistant with the
partial ordering imposed by their interdependences, and THAT file
should be able to be compiled (with the gcc command line shown in
the script above) with zero errors and warnings. (I will volunteer
to determine/document the partial ordering if anyone else is
willing to then get in and fix all of the header files bugs which
will be revealed by compiling the hypothesized .c file, but I won't
waste my time doing this if nobody gives a damn.)
[5] Taking the ordered list of #include statements generated as per [4]
above, another potentially useful QA test is to attempt to compile
a .c file containing that ordered set of #include's followed by
another copy of that same set. This will flush out all cases of
system include files that cannot be included twice in a given
compilation without incuring `multiple definition' errors, e.g.
<isofs/cd9660/iso.h>. Once again, I use the ANSI/ISO C standard
as my guide - It requires that each and every system include file
which *it* mandates must be capable of being included twice into
the same single compilation WITHOUT incuring compile-time errors.
[6] For extra credit, take the script shown above and replace "gcc" with
"g++' and then re-run. In this case also, neither errors nor warnings
should ensue.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
