Re: type based aliasing again

[craig@jcb-sc.com]

If a warning is simple enough to add that it takes only a few lines
occurs in an obvious place, and doesn't experience a change in its
"envelope" due to reasonable changes in how a compiler internally
represents things, I'm all for it in a product like GCC.

That's not my impression as to how *this* proposed warning is likely to be
implemented.  That's why I'm not in favor of it, along with the fact
that this issue is already taking up far more valuable time on these
lists than it *ever* deserved.

[Joe wrote:]
>Exactly; post violations I've seen are of that type.  I can't aspire to
>the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps
>missing this point: a whole lot of the errors we've seen are of this
>extremely simple form, with the entire error appearing in two or three
>adjacent lines of code.  We know the exact offsets of each address and
>can clearly see that they collide.

Let me see if I can explain my concerns here.

If we introduce the proposed new warning in GCC, it will require not
only some significant changes to implement, it *will* require extra
work to maintain.  Forever.  Until the end of time.

That's because the mere *apparent* promise that GCC will warn about
suspicious constructs will be enough to persuade too many people that
they don't need to audit their code, line by line, and fix the problem.

[Joe later wrote:]
>My intent, which may be different from RMS's intent, is to help users
>get rid of this variety of invalid code, not to perpetuate it.

I agree 100%.  I believe this proposed warning will be interpreted by
much of the user base as a reliable indicator of when to turn off
alias analysis rather than of when to fix their code, based on how
this issue has been treated in these discussions.

So those people will rely on GCC holding their hands.  Most of the time
it might be correct.  Too often, it will be wrong.  We will blamed
when it is, just as we've been blamed *already* for providing a *correct*
compiler with a *simple* workaround for buggy code.

Remember, some of you have already been seriously considering having
the mere *warning* trigger a *different* code-generation strategy.
Why?

I think the answer is pretty clear -- it's because you already know,
deep, down inside, that the real agenda here is to make it easy for
people who think GCC really *should* support their alias-concern-free
variant of the C language to continue to write code *their* way.
Then they'll just ignore, or filter out, the warnings.  (If the FAQ
could say "don't do that", then it could just as well say "use
-fno-strict-aliasing".  Hey!!  It already does!  Then why are we
having this discussion, if we are going to assume people will read
the docs?)

If that's not the case, then please end all discussion of the warning
turning off aliasing.  That's no more sensible than having the
uninitialized-variable warning triggering the automatic bzero-ing of
the stack frame upon entry to every procedure, along with all sorts
of other "friendly" things for warnings to do.

Now, I already *know* all the counterarguments to this concern.

But every one of them can be applied to the *current* situation,
where we have *no* warnings, -fstrict-aliasing is the default,
and users have the -fno-strict-aliasing option:

  -  "We can tell people not to rely on the warnings, or lack thereof,
      as any sort of substitute for fixing their code."

     Oh sure, tell them to read the docs.  Sorry: that didn't work
     in the first place to get them to write ANSI/ISO-conforming
     code *or* to get them to use -fno-strict-aliasing.  If you think
     they'll go away just because a new warning appears, please
     cite your evidence for that tactic working under similar
     circumstances -- I'd love to see it.  (Having worked on g77,
     which has a *far* more forgiving audience, in this sense, than
     gcc, I know firsthand how new warnings are received, no matter
     how well they're documented.  They're no panacea.  And I suggest
     the g77 warnings I'm thinking of are, and have generally been,
     *vastly* better documented than GCC warnings -- so if you think
     you're going to avoid a substantial number of complaints and real
     problems with this warning, you'll have to document it better
     than g77 documents any of *its* warnings, IMO.)

  -  "It's important to catch *all* the possible problems somehow,
     so as to avoid generating bad code."

     Not only is the warning idea going to *fail* at that, there's
     *already* -fno-strict-aliasing.  That is the most reliable
     method we're going to ever offer.  Period.

  -  "We're just trying to address certain common cases that occur
     within only a few lines of code, not get at all the problems
     at once."

     A much more reasonable stance.  I suggest someone write a few
     lines of Perl, Scheme, or some such thing to do the job.  Please
     leave it out of GCC internals, though it could be shipped with GCC.

  -  "But people expect GCC to do all these things for them."

     It can't and won't, so we should pick and choose the things it'll
     do best.  That Perl/Scheme script?  Using the time/energy spent
     conducting pro-munging-GCC campaigns on these lists, I'm sure
     a "clever programmer" or two could not only have written it,
     but tested it *and* distributed it, perhaps two or three versions
     by now.

     What the C community needs is a tool to find this particularly
     gnarly problem.  It should view it as a use-once-and-fix-thereby
     tool.  Fixing this problem is like fixing the Y2K problem.  Do
     it once, and do it right.  Putting the same functionality in
     GCC suggests more of an ad-hoc approach to deciding whether to
     tolerate, fix, or ignore the problem.

     And the users who supposedly need this solution *now* could get it
     *now* if you'd (whoever you are) just go and write it, distribute
     it, and not make them wait (even longer) for GCC 3.0.  (Longer
     because of the time it'll take to add, document, and write test
     cases for this new warning.  And what happens when, one month
     before scheduled release, someone notices that the warning doesn't
     work right on *one* platform, like the uninitialized-variable
     warning awhile ago on Alphas?  Do we delay the release to fix
     this warning, which is supposedly so crucial we've spent all this
     time discussing and installing it, or blow off the importance of
     helping those poor, confused C programmers on a major platform?)

  -  "It's much easier to change GCC to warn about this than to write
     a new script, especially when it comes to certain cases."

     I suggest that if a simple script can't catch the problem, a GCC
     warning, even if it worked, wouldn't help users catch the problem
     any more than they're helped now using -fno-strict-analysis.  (That
     is, such users have *already* claimed they're not going to fix
     code where the problem is strewn throughout.  I'm thinking of Linux
     here.  And whatever the Linux cognescenti decide, many thousands
     of programmers will surely do as well.  In that sense, Linus and
     David Miller have given us tremendously valuable input -- a preview
     of what, say, 1000 programmers will be screaming at us about one
     year after Merced, or McKinley, comes out.)

     But, if you like, snarf a copy of GCC, strip out all the code
     generation, and add the patch you think is so easy to warn
     about the problem.  Make it a separate product, on its own
     release schedule.  Same reasons as above.

     In other words, have GCC distribute not only cc1, protoize, and
     unprotoize, but findalias as well.

  -  "But the proposed warning won't make GCC much more complex."

     Perhaps not, but every little addition like this requires all *future*
     maintainers of GCC to cope with that much more state, that much
     more complexity, and, most difficult for new, enthusiastic
     developers to cope with, more "quiet expectation" that the "envelope"
     of the warning (the circumstances under which it is and is not
     issued) will never change or, at least, will only "get better".
     With *this* proposed warning, I think that's going to be particularly
     challenging, based on the discussions of the technical aspects of
     it.

The wording Joe used earlier, "the mode of treating the user like
an opponent", bothered me because it implied that any refusal to
add new "features" constituted opposing users.

That is probably not what Joe intended, but, let me say, the willingness
to add any new feature asked for by users *can* constitute opposing
the ability of your "e-descendants" to continue to maintain the
product as a going concern.

So, while a warning (that has no effect on code generation) *might* be
a good idea, I tend to think that, in this case, it is not, based on
a rather quick reading of the original (recent) proposal.

As back-up to my positions, I suggest readers review archives (wish
they could do so of the gcc2 postings I remember from years back)
vis-a-vis complaints and hassles when much simpler (conceptually)
warnings didn't behave as expected, such as uninitialized-variable
warnings; and vis-a-vis claims about how GCC should cater to "clever
programmers" (their own words) by providing essentially endless,
detailed control over every aspect of code generation, even if doing
so is at the expense of delivering a robust, high-performance,
predictable compiler for "non-clever" programmers who actually
follow the standards, read the documentation, and rely on much more
than "well, it always worked that way before" to justify their
requests.

In the end, it's a question of what kind of users we want to cater to.
I've found it much easier to cater to people who "read the directions",
so to speak, than those who ride by the seat of their pants.  YMMV,
but it should be easy to see why catering directly to the former
allows the latter to continue to operate however they like -- catering
to the latter makes the product worse for direction-followers and
only encourages the direction-ignorers to take even more risks.  (Which
was the point I was trying to make with my previous post containing
the shell script -- exactly the sort of thing a "clever programmer"
would invent *and* expect to always work.)

        tq vm, (burley)