From owner-freebsd-hackers Wed Jan 5 10: 9:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from monkeys.com (i180.value.net [206.14.136.180]) by hub.freebsd.org (Postfix) with ESMTP id 0F53B153B0 for ; Wed, 5 Jan 2000 10:09:22 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (localhost [127.0.0.1]) by monkeys.com (8.9.3/8.9.3) with ESMTP id KAA98341; Wed, 5 Jan 2000 10:08:54 -0800 (PST) To: Martin Cracauer Cc: mauzi@poli.hu, hackers@FreeBSD.ORG Subject: Re: [OFFTOPIC] alt. C compiler In-reply-to: Your message of Wed, 05 Jan 2000 10:07:16 +0100. <20000105100716.A63545@cons.org> Date: Wed, 05 Jan 2000 10:08:54 -0800 Message-ID: <98339.947095734@monkeys.com> From: "Ronald F. Guilmette" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20000105100716.A63545@cons.org>, Martin Cracauer 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. . 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message