Re: Linux and aliasing?

[craig at jcb-sc dot com]

>On 4 Jun 1999 craig@jcb-sc.com wrote:
>> 
>> 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.
>
>Oh?
>
>That's a new argument. Instead of "don't use that feature", it's now
>"don't do anything clever at all".

No, you misunderstand.

C is simply a poor language for the task at hand.  It provides too
little low-level control of how a C compiler should do its work,
yet it's not high-level enough to make it practical for the compiler
to do enough of the optimization work for the programmer to satisfy
developers of embedded/OS code.

Your recently-expressed concerns about `volatile' were a perfect
example of that.  You correctly (or pretty nearly so) noted the
distinction you wanted to make between a volatile *reference* to
an object and a reference to an object via a volatile *address*
(pointer).  That's a distinction C apparently doesn't provide,
among many, in a language supposedly "suitable" for "low-level"
coding (and, I admit, it's better than PL/I in that regard).

Not that I have anything great to suggest in place of C, you understand,
and I fully realize that you're not about to rewrite Linux into some
other language anyway.

But what you're essentially asking for is for us to make gcc compile
some language that is less and less like C, one that is more and more
like your particular *vision* of what C should be, which happens to
be quite at odds with the direct C9X and others are taking, if my
impressions of those efforts (based on posts to this list) are
correct.  (Clearly it'd be easier if those working on the upcoming C
standard simply implemented your desires...at least, easier on the
gcc developers.)

Further, you're asking for us to do language design "on the fly", while
implementing a compiler for that language.  In my experience, that
attempt to marry language design and compiler implementation, while
plenty of fun and full of opportunity for cleverness to show itself,
almost always leads to poor language design.

You've already been bitten by hard-to-find bugs stemming from *extensions*
to GNU C that you used, sometimes without regard to the fact that they
were not particularly well documented.  These experiences have led you
to conclude, or at least complain, that gcc was going in a direction
you did not like.  (Worst of all, you often express this by insulting
people like myself, who, especially in my case, aren't the ones *causing*
the trouble, but are simply trying to *explain* it to you!)

Now you are complaining about a *standard* language feature being
implemented in a standard-conforming way by gcc, one which you can
work around by changing your code to be standard-conforming (surely
a SMOP, say a few lines of Perl ;-) *or* by using a command-line
option...but you don't like the pain of the former, or the performance
of the latter.  Welcome to C hell.

I don't know the details of the issues involved, but I trust those that
have spoken against your proposal, that they *do* know them.

What I have been trying to do is get you to see that, at some point,
you have to conclude that you're never going to succeed at making
the edge of *this* particular hammer, gcc, sharp enough to make
nice clean cuts in silk, for any length of time, without a whole lot
of pain, because every time someone uses it as a hammer, those nice
cutting edges get worn off.

        tq vm, (burley)

P.S. Due to my own outbursts on this thread, and the resulting email
I got, I promise to make this the *last* time I will *ever* respond
to queries, complaints, etc. about similar issues coming from the
Linux camp.  Clearly I do not have what it takes to respond to what
I see as extreme (and repeated) childishness without letting myself
be dragged (at least somewhat) down into the muck, a problem I've
long known I've had, but have yet to fully address.

So, those of you who *encouraged* me in private email, thanks, but,
from now on, you're on your own in defending the honor of gcc
developers against the unfounded, and unfair, accusations of people like
Linus Torvalds.  It's not just that I don't have the maturity to
cope with it -- I don't have the patience, and I surely don't have
the time, to keep going over the same ground again and again.