Re: type based aliasing again

[craig AT jcb-sc.com]

>> If it's not a feature, then backwards compatibility is not an issue.
>
>  I believe the above sentence is untrue. The behaviour of the compiler
>has changed, reguardless of any lables we might throw on the situation.

I already addressed that: the behavior of the compiler *always* changes
upon installing a new release, else there's no point in installing,
or even creating, it.  (Not quite 100% true, but let's say 99.9% of the
time, that's all true.)

If you don't want the behavior of your program changing due to a change
in the compiler and/or version used to build it, then it is up to you,
the author of that program, to specify exactly which compiler/version
is to be used.

>  However, this change is one that can affect the correctness of the users
>code.

No.  It is correct to say "this change is one that can expose the
incorrectness of the user's code".

And that can be said of almost *any* change made to the code-generation
facility of a compiler.

>If we can warn the user by writing a reasonable amount of code then
>it seems to be the "nice" thing to do. Even if we can't catch all
>occurances (as is mentioned earlier in this thread), the ones we can catch
>may be quite a help to the user. 

I agree with that.

>  The assembly thing (which I don't 100% understand - I have no need to
>use it so I don't completely know the issue) is a good example, I think.

It's simple.  When you do "gcc foo.c", you get an a.out executable,
but that process, behind your back so to speak, generates, among
other things, an assembly (.s) file containing the low-level machine
codes the compiler picked to implement the code in foo.c as
mnemonic instructions.

Those instructions represent the closest thing the software industry
has to a widely understood "fix" of how the code in foo.c is actually
implemented by the compiler, e.g. given "i = j++ + k++;", whether
j or k gets incremented first.

If you, as a programmer, wish the behavior of your *program* to not
change, you can, as I said, simply designate a *particular* compiler
and version combination to use (for a particular platform, say).

And if you don't want to require people to have that particular
combination on their machines to build your program, but want
them to have the source code at some level, then provide them
the assembly (.s) file along with your source code, and instruct
the user (via Makefile, perhaps) to "compile" (really, assemble)
*that* instead of the .c.

>The behavior of the compiler was deliberatly changed. I don't care about
>what the documentation said, or who was broken before, or any of that. The
>fact is that code that used to work began (as I understand it) to fail
>silently. This is bad, even if it IS in an FAQ somewhere. Now a warning
>has been added. So the change, which is a positive one, gets to stay, but
>the user gets fair warning from the compiler.

The *developer* of the *code* already got fair warning, or else is a
dunce who shouldn't be allowed anywhere near a computer, especially
not as a programmer.  Only people who understand, or at least accept,
the fact that re-compiling their code can legitimately change the apparent
behavior of their code should be allowed to represent themselves
as programmers in languages requiring compilation (or even interpretation).

Otherwise they should restrict themselves to programming in assembly
language.  And to a very simple machine model at that.  I suggest
the PDP-8.  If they can't fit their programs into 32K 12-bit words
in PDP-8 assembly code, they aren't real programmers anyway.

Now, what *users* expect is a whole 'nother can of worms.  If users
need fair warning that a program might not work because they use a
different compiler on it, then that warning must come from the
developers of that *program*, not the compiler.

>  Now imagine that this export thing, instead of spewing an error,
>silently went on to miscompile the code.

Well-designed languages are that way to the extent that they make
it easy for compilers and interpreters that implement them reject,
or at least warn about, erroneous constructs that programmers might easily
enter, and that means those rejections and warnings are seen by
the *programmers*, not the *users* of the program.

That's the problem with this whole notion that it is up to GCC to serve
as a sort of free-software installation tool.  It is the *programmer*,
not the installer, that needs to see the warnings.  GCC can't do that
as a free-software installation tool.  It can do that, in some cases,
when properly used as a *compiler*.

Still, since C is not exactly a well-designed language, it is not
easy to write static-code-checkers (a la the lint-like facility of
GCC) to find all the problems typically committed by programmers.

>  It is unfortuante that it is immpossile to spew a warning on every
>instance of the alias problem, but I think it is necessary to provide a
>warning when we can do so with a minimum of effort.

I think everyone agrees to that.

What is not widely appreciated or understood is that this warning
*probably* will, itself, "change" across versions/releases of GCC,
and that programmers and users will be as upset about those changes
in *this* case as in the case of alias analysis becoming the default.

Am I wrong?  Well, after *tons* of exactly correct pointing out of
the issues, correcting *many* people on this list, as done by people
such as myself and Mark Mitchell, can anyone point to a *single*
example of anyone admitting they had been wrong and now understood
that they should not expect a compiler to never change the behavior
of their program, especially if it invokes undefined behavior according
to the pertinent language standard?

So I can see why a few people might think even a warning is likely
to constitute just another new minefield for GCC developers to
have to march through in another year or two.

That's why I strongly resist a warning implemented by having to
change code-generation strategies.  If the new strategy is preferable
absent any difference in warnings, fine; then, presumably, the
new warning *can* be easily added and maintained.

But anyone who thinks GCC developers can avoid this whole problem
(of huge amounts of argument about how GCC is "breaking programs")
by making it warn about this construct is, frankly, deluding themselves.

>> And there is no current silent corruption that is default in GCC
>> as pertains this thread.  If you believe that, you were misinformed,
>> and should abstain from repeating this misinformation in any other
>> forum in the future.
>
>   ? Please explain? I thought the whole point of this thread is the
>effect that alias analysis has had on Linux, god knows what else, etc. I
>though the effect was "incorrect" code (code that does not run as
>intended) generated by gcc since it assumed that ANSI rules were being
>followed by the source. Maybe silent corruption was a bad choice of words,
>and "incorrect" code (including the quotes) is a better one.

See above.

>> The whole problem here is simply one of miseducation, or ignorance,
>> on the part of people who think they know what GCC is.  We need not
>> change one line of code to fix *that* problem, and if we don't
>> fix that problem, rewriting GCC from scratch will not fix it either.
>> Certainly changing a few lines will have no worthwhile overall effect.
>> 
>
>  Ok. What is GCC? Gcc to me is the free/opensource/whatever compiler
>maintain by the GCC team, which is an absolutly essentail part of the free
>software movement. I'm not sure what this has to do with the discussion at
>hand.

Some people think GCC is a hand-holding catch-all for installing
free software from source, regardless of the correctness of that
source code (as long as it might have seemed to work on some
old version of some C compiler somewhere), or some approximation
thereof.

That's why they think that GCC is now breaking programs by
defaulting to employing its alias analysis.

People who don't clearly understand the proper roles of various
computer programs, programmers, and end users will *never* be
able to produce well-engineered products.

        tq vm, (burley)