Re: PATCH: change splay_tree_key & splay_tree_value types to void*

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Greg" == Greg McGary <greg@mcgary.org> writes:

You asked about overhead.  We got to about 3:1, I think.  Perhaps a
little worse.  Life was harder for us in that we had to emit source,
not object code.  So, we did not have builtin support from the
libraries.  Slow enough to be noticable, fast enough to be useful.

The usual usage mode for error-checking tools (despite whatever the
user's manuals say, or what we as their authors might hope) seems to
be that people use them only when they have problems.  They turn them
on when they have a bug that can't be tracked in some other way.

    Greg> And I'm trying to emphasize that leniency is not so
    Greg> important for what I consider to be my user base.  It seems
    Greg> that your experience as a commercial debug tool builder for
    Greg> a commercial SW development market where closed-source is
    Greg> the norm leads you to believe that leniency is important.
    Greg> However, I am designing and building BPs for my own use and
    Greg> for the use of free/open source community where the
    Greg> landscape is entirely different and leniency is not very
    Greg> important.

I think that my background is probably not relevant.  A lot of the
software we worked with was open-source: for example, Tcl/Tk and GNU
binutils were a lot of our test-code.

I also think it's a mistake to look down on proprietary developers in
this respect.  For example, many of our customers were making
mission-critical software for communications systems or even
satellites.  Failures were extremely costly, and people really did
care a lot about quality.  Management for these systems bought lots of
expensive tools to help with error-detection and simulation, and
dedicated considerably more resources than I have ever heard of on
free software to testing, quality assurance, and so forth.  There was
often extensive code review before testing, and extensive design
reviews before coding.  There was definite willingness to make changes
both in process and in code to achieve higher quality.

"For my own use" may be the key phrase.  I would be happy to have full
strict everything checking for new code I write.  (Well, even there,
maybe not.  For exmaple, if my code doesn't work on platforms where
different pointers have different sizes, I probably don't care, even
though that could be a conforming platform.  Same probably goes for
platforms where NULL is not reresented by a value all of whose bits
are zero.)

I agree that what you have found in binutils is a bug.  However, it
is, as you say, harmless.  Besides the satisfaction of having cleaned
it up, how much of a difference does fixing it really make?

A harsh question, but I do not mean it as a criticism.  It's good to
have fixed the problem.  The question is whether or not you want users
of bounded pointers to go tracking down those kinds of bugs, instead
of the other more important problems you'll catch.  Users won't know,
until they track them down, what problems are more severe, which is
why achieving a very low false positive rate is so valuable.  That
makes users trust the tool.

By the way, here's another example of the kind of choices we had to
make, although they are slightly outside the scope of bounded
pointers.  These were issues we worried about in our tools, though:

  - Should copying uninitialized memory result in messages, even
    if the memory is never used?

    For example, in some data structures field `x' is only used if
    field `y' has a particular value.  But copying the struct
    copies both fields.  Is that a bug?  Maybe.  The standard
    says behavior is undefined at that point.  In pratice, it's not;
    as long as the access invariant holds, and forcing programs
    to initialize everything makes them slower.

  - Should declaring a function with a different prototype in 
    one file from another be an error?

    If the function returns `int' in reality, but is declared to
    return `void' elsewhere, is that a bug?  Again, it is technically
    a bug, but it is not in practice much of a problem.  If the
    definition is in a library, and the library .a contains special
    information indicating that the return type is `int' (put there
    by the error-checker), and the bogus declaration appears in 
    a header file provided by another library, what would you have
    the hapless user do?

Luckily, for the purposes of bounded pointers you do not have to solve
these problems!  But, there are others, just as nasty, I fear.

The harsh reality is that even in the land of free and open-source
software a lot of people do not want to make changes to their code
that make their code more technically correct.  Even if those changes
make the code run faster!

I also don't think the "all-source" model really makes sense in the
long run.  Already, many of us have free software for which we have
never compiled the source, nor wanted to.  I would love to use bounded
pointers with my Gtk code, but I really don't want to have to
recompile Gtk, or even have to download a `GTK BP RPM' or
whatever. And if that leads to false positives because Gtk hands me
back a `char *' I gave it, but without the right bounds, I think that
is a serious problem.  (I would hope that someone on the Gtk team has
tested the Gtk library with bounded pointers so that I could have
increased confidence in Gtk.)

Your code will get much more use if you are more tolerant: both of
quasi-bugs and also of people who want to mix instrumented and
non-instrumented code.

    Greg> IMO, you seem too eager to undermine BPs in deference to
    Greg> code that is somewhat dirty and questionably portable, but
    Greg> otherwise in line with common practice.  I just can't agree
    Greg> with that philosophy.

Since I, when I first when to CenterLine, thought much as you do now,
I understand where you are coming from.  Hard experience convinced me
that the leigions of people who told me to be lenient were right.  

I do not know of any way to convince you beyond that annoying "I've
been here before" kind of rhetoric, so I won't try any further.  You
probably already think I am obnoxious. :-)

In order to reduce my obnoxiousness quotient, I won't waste your time
by pedantically pontificating any further!  As you say, we can agree
to disagree.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com