Linux and aliasing?
Fri Jun 4 05:47:00 GMT 1999

>Craig, don't always try to make the programmer look bad.

Why would I, since you seem to be doing such a good job of it, by
coming here and lecturing us about how to build compilers?

My goal is to make *great* programmers look *better*.  If gcc is
really a tool, it'll be simple, easy to use properly, and behave
consistently no matter where it is used.  *Great* programmers
prefer that kind of tool.  *Lousy* programmers think a hammer should
behave like a screwdriver so they can save some time changing tools
in the middle of a job, or so it can be "compatible" with the
locals' tradition that something called a "hammah" does the job of
a screwdriver.

>Instead of blaming the
>programmer, please just _allow_ him to say "you're just a stupid compiler,
>and you shouldn't be getting too much in my way". Is that so hard to do?

a) you already have the ability to do that, but you seem to not like
it, and b) yes, when it *is* so hard to do that, when there end up
being 5,000 different controls like that, and we decide that, lo and
behold, there's a *bug* in there somewhere, or, hey, maybe we want
to rewrite a chunk of the compiler, and it seems simple enough to do
that, except, first, we have to do an in-depth study on exactly how
those 5,000 controls might interact (since we have little or no
useful documentation on them, other than existing code that might
break if they stop behaving exactly as they did).

>Again, instead of thinking that the compiler always knows best, give the
>user a choice. We're not in Windows any more, Tonto. Give the programmer
>the gun, and allow him to shoot himself in the head. But give him a
>laser-guided nightsight too, in case he wants it.

Any programmer worth his salt, wanting "a laser-guided nightsight",
and not wanting to tweak (or even rewrite) his code for every new
compiler release, will *not* use a C compiler.  Period.

>Don't get caught up in the MS way of doing things, where you not only give
>a programmer a gun, you aim it at (roughtly) the wrong target, and you
>pull the trigger for him too. 

The MS way *is* to offer a product with bazillions of little features
that are not really appropriate to the "core mission" of the product.
Or what do *you* call MS Word -- a word processor?  Nobody I know,
who understands design issues, calls it that.

>Face it, there are clever programmers out there. You shouldn't make it
>illegal to be clever. A standard is not a law of nature, and it's not a
>universal excuse to be unfriendly to people who want to go outside the

I would prefer gcc default to catering to *great* programmers.  *Clever*
programmers make the fatal mistakes we all have to live with, like
making distinctions based on content of whitespace, or believing that
a key labeled "backspace" must necessarily generate ASCII BS simply
because they share the same name, or believing that their code will
be rewritten and deployed before Jan 1, 2000.

Put another way: I *know* there are clever programmers out there.  That's
what scares me.

Face it: *you* made the fatal mistake here, by choosing C to implement
an operating system that you wanted to be fast, easy to maintain, and
portable.  Even worse: you choose "GNU C", the C language extended by
people who larely didn't understand what they were doing.  And, I agree
100%, all the people making these mistakes, from yourself to RMS, are
"clever programmers".

But you can mitigate the mistakes *you* made by dropping at least one
of the requirements you appear to have for Linux:

  -  Speed.  Rewrite it to accommodate some reasonable subset of ISO C,
     then live with whatever performance you get by tweaking compiler
     options.  That means no `asm', of course.

  -  Easy to maintain.  Decide that, upon every new release of gcc you
     want to compile Linux, you'll commit significant resources studying
     the effects of new optimizations and rewriting *Linux* -- not *gcc*
     -- to accommodate it.

  -  Portable.  Decide that gcc 2.7.2 will forever be the compiler for
     Linux, and that you'll therefore live with never porting Linux
     to new architectures not supported by that version of gcc.

The above will be recognized as a variation on a well-known theme --
"you can have it Soon, Cheap, and Working; choose *two*".

It would at least help us some, in accommodating cases (which, for all
I know, is true of this particular issue, though other gcc contributors
suggest otherwise) where we really blew it in selecting a default,
if you'd focus on the middle item more, to the extent that it results
in sharing what you learn about the effects of new optimizations, etc.
on the existing Linux code base.

I mean, I do recall some discussions of this issue before, but why
are we discussing it *now*, in a release cycle, when there's *nothing*
we can do about it, given that there's no *bug* here?

        tq vm, (burley)

More information about the Gcc mailing list