This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: change splay_tree_key & splay_tree_value types to void*
Mark Mitchell <mark@codesourcery.com> writes:
> I also think it's a mistake to look down on proprietary developers in
> this respect.
I didn't mean to convey that attitude. What I think about them is
that they sometimes have a much harder job to do because of licensing
barriers to source availability.
> For example, many of our customers were making mission-critical
> software for communications systems or even satellites.
One of the intended uses for BPs is for Lucent/INS (nee Ascend
Communications) embedded router code. Happily there are no
binary-only libraries. We buy plenty of code from vendors, but it's
always source and we always build systems from 100% source.
> "For my own use" may be the key phrase. I would be happy to have full
> strict everything checking for new code I write.
I considered whether or not to include that phrase, and left it in
since it's true. However, "my use" doesn't imply new code. The
Lucent/INS embedded OS is a monolithic monster considerable weight and
complexity. The source tree is 200+ MB. It runs on 5 CPU
architectures (MIPS, PowerPC, i960, m68k, a29k) over a large range of
products (#if'd up the wazoo!) from single-user ISDN CPE to 40-slot,
8000-port remote access switches. "My use" includes running BPs on
this beast, so I expect some bloody battles ahead. FYI, I did get far
enough with an older gcc-2.7.2 BP implementation to have an i960-based
72-port remote access switch boot and pass POST, finding 6 real, but
"low priority" initialization bugs along the way.
> 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?
It gives me confidence that strict checking will find bugs that other
tools overlook. Purify can't touch bugs like that. Once it's fixed,
and then runs without incident, I have a high degree of confidence
that there are no bounds violations. If I were to run in lenient mode
so that this bug was swept under the rug, I'd worry about what other
bugs were swept under the rug as well. Those bugs might be harmless
now, but later changes might expose them at which time the debugging
cost will doubtlessly be higher.
> A harsh question, but I do not mean it as a criticism.
Harsh? An easy lob! 8^)
> 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.
Yes, I want users to catch and fix those bugs, in exchange for the
confidence that BPs will aggressively ferret out any and all marginal
bits of code. Those bits might be harmless today, but they're
accidents waiting to happen and become dangerous if surrounding code
changes, or data layout changes, or the program is ported.
> 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.
We must be careful not to cut the false positive rate at the expense
of raising the false negative rate. I'll gladly find & fix a dozen
false negatives if that's the cost of exposing a real bug that might
otherwise slip through if I relaxed the checking. That's my personal
preference, and surely there are those who share it, as well as those
who don't.
> 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!
Time will tell how much of a problem that will be. I haven't yet
submitted a patch for bfd/archive.c, so it remains to be seen how much
resistance I'll get there. I hope that demand for BP'ized libraries
will be sufficient to persuade maintainers to accept patches that make
them BP-clean. I don't expect maintainers to necessarily do the
BP'izing work themselves, but do expect a reasonable level of
cooperation in accepting BP-cleanliness patches and BP'izing makefile
infrastructure. Again, time will tell.
> 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.
I understand your hesitance to be a pioneer-builder of a BP'ized
library, but I don't have much sympathy for unwillingness to load a
BP-RPM that's handed to you on a platter. Roughly half of the bounds
violations I have found to date manifest deep in the bowels of libc,
e.g., the user hands a too-short buffer to sprintf and the violation
occurs when libio tries to write a character beyond the end of the
buffer. An unchecked libc lets that bug pass. Just because a library
is perfectly bug free doesn't mean it need no longer be used in its BP
form. Checked library code finds bugs in application code that feeds
the library bad input.
> 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 don't know Gtk well enough to appreciate your abstract example.
How might Gtk plausibly mash the bounds of a char* that you give to it?
> (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.)
I'll put Gtk on my list of test fodder, and have a crack at BP'izing
on your behalf.
> 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.
Sure, I agree in principle, but I have enough users for now--only
myself! However, I don't think the user base is so small because BPs
are too strict, but rather because they're too new and largely
undeployed. When a major Linux distribution releases BP-capable GCC &
binutils, with BP'ized glibc and a good number of other BP'ized
libraries, then we'll see how usable strict BPs are and how strongly
users agitate for leniency. That day is at least a few quarters away.
> 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. :-)
Hardly! This has been a useful debate. Thanks for enduring my
stubborn resistance to superior knowledge and experience! 8^)
Greg