NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/sysv386/16404

Internet Message Format | 1992-11-11 | 3.9 KB

Xref: sparky comp.unix.sysv386:16404 biz.sco.opendesktop:729 biz.sco.general:4113
Newsgroups: comp.unix.sysv386,biz.sco.opendesktop,biz.sco.general
Path: sparky!uunet!caen!destroyer!mudos!mju
From: [e-mail] (Marc Unangst)
Subject: Re: Bug with ScoSession connecting to XTerm with >16 colors
Message-ID: <[e-mail]>
Date: Thu, 12 Nov 1992 02:31:50 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: The Programmer's Pit Stop, Ann Arbor MI
Lines: 61

In article <[e-mail]> [e-mail] (Craig Macbride) writes:
>A better solution would be for ANSI to realise that including C checks in
>the pre-processor is a _bad_ idea, since the C preprocessor is widely
>used as a general preprocessor. This is a classic instance of ANSI creating
>a situation whereby its "standard" behaviour gives no advantage over the
>old situation, but breaks heaps of existing applications.

The fact that the C preprocessor on Unix has accepted non-legal C code
in the past is more or less a historical accident of the compiler
design, and certainly not something that was designed-in as a feature.
(This is, of course, speculation, but I suspect that it's correct.)
The only reason that the C preprocessor doesn't barf on illegal C code
is that it would be more work for it to do so, since the code is not
actually parsed for compilation purposes until a later pass of the
compiler.

However, the ANSI committee did not desire to make things more
difficult for the compiler writers, and in addition wanted to give
them as much flexibility as possible.  So, the ANSI specification says
that the C preprocessor's behavior is "undefined" when it is not fed
legal C code.  (A user-friendly compiler, of course, might either give
you an error or try to forge on anyway, but the compiler is free to do
whatever it pleases, including executing "/bin/rm -rf .".)  This
allows a compiler writer to make a one-pass compiler that does
preprocessing, code parsing, and assembler-code generation all in one
step.  Now, if you had a compiler that behaved like this, exactly how
do you go about feeding something to just the "preprocessor", and
arranging to get your output before it makes it to the "code parser"?
And what is the compiler supposed to do with something that isn't
legal C code, when there are no separate preprocessor and code-parser
passes?

Also keep in mind that ANSI was not writing a standard for Unix, even
though you might think of Unix as the environment where most of the C
code in the world gets written and compiled.  Does Borland's Turbo C++
have a separate C preprocessor pass that you can feed arbitrary text
to?  And get something other than error messages out of when you do?
And why should they bother to include something like that, when
they're selling a C compiler instead of a stream-editor?

I will reiterate: If you want a general-purpose text processor, then
use one.  Don't try to cobble something together out of other
(unsuitable) tools, and then complain when the resulting mess doesn't
work the way you expect it to.

>Even if ANSI don't ever get their act together, the good folks at SCO
>should at least realise that removing capabilities from their product
>doesn't win them any friends and keep the old cpp available in some
>form or other.

SCO doesn't write any of the C compilers they distribute.  Microsoft
writes the compiler distributed as /bin/cc, and AT&T writes the
compiler distributed as /bin/rcc.  I believe that in SVR3, the AT&T
compiler was still K&R instead of ANSI, so if you can find the AT&T
preprocessor you should be able to use that on arbitrary text.

--
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
[e-mail]   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture