[ On Tue, July 25, 1995 at 13:21:58 (-0400), der Mouse wrote: ]
> Subject: Re:  Why is using "inline" as a variable name a parse error for our compiler?
>
> They perforce are to some extent, since you can't both have prototypes
> and not have prototypes.  Stuff like __P() makes it relatively painless
> in most cases, by making you tweak at most one thing to turn prototypes
> on or off.  We are depending on a gcc extension (see below), but it is
> relatively easy to write code that's compilable under old compilers and
> still fully prototyped and correct under gcc (but in some cases not
> other, more strictly ANSI, compilers).  Here's a snippet from the gcc
> 2.7.0 distribution's extend.texi that talks about the extension:

Yes, I'm aware of those problems....

IMNSHO, ANSI-C should never have taken on the type-coercion feature of
prototypes.  This is definitely a new invention, and as we're seeing,
one that causes portability problems -- something the standard was
supposed to avoid at all cost.  The old K&R type promotion rules should
have been kept even though they themselves cause some problems.

> Perhaps.  But why bother?  A lot of the complexity and expense goes
> into things that (like, say, preprocessing and codewalking) have to be
> done in both cases.  Keeping it all together in one program makes
> maintenance a good deal easier, and if you don't want to pay the price
> of the warnings, just don't turn on those flags and the only price
> you'll pay is some text segment space that never gets used.  And a few
> tests to see if you turned on the flag; I think that price is tiny for
> the benefits gained.

I don't mean forever separating them -- take a look at the original AT&T
compiler/lint implementations.  The code should obviously be shared
where possible.

Note that proper lint checking *cannot* be done without either including
every header with prototypes in every module, or else doing what lint
does and keeping parser output libraries for the whole project (and all
of the system libraries!).

Anyway, I digress -- such changes are not likely in the future of GCC.

> Besides, how often do you just recompile untouched code?  I do this
> pretty damn seldom; I'd always be running the full-checking version.

I re-compile un-touched code almost all the time.  I do fresh builds for
new systems far more often than I ever change code, except when I'm in
the depths of developing something.

I.e. I want a *production* compiler that's job is purely to compile.
I'm far more happy with a lint checking tool while developing (or even
an interpreter!) than I am having to use a top-heavy compiler, meant for
the old-style edit-compile-edit cycle many programmers use, all the
time.  Thank heavens Plan-9's compilers aren't top-heavy.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>