Could you say a little more about what the change was? Was it one error, 500 times, or 500 errors? Was it a compiler warning, or an error that blocked compilation?

Also, I object somewhat to your description of error prevention as "care." Developers who either don't know about a problem, or are too pressed for time by management are not being careless, they're making an economicly rational tradeoff between perfection and shipping code.

How soon after format string errors were discovered would adding one to your code be "careless?" To say that another way, there's a reasonable level of care and education we should expect today, and then there are new bugs. The output of RATS would allow you to distinguish, somewhat.

> Four hours later, and I'd edited about 100 files and changed
> about 500 lines of code. My eyes eere glazed, my brain frizzled

Using a refactoring tool might have helped...

-- O.L.

Trust me to open my mouth when there are coding experts in the room...

OK, what the Java compiler now grumbles at is variable name shadowing. In the past, it would grumble if a method's variable name was the same as an object's variable name, quite rightly pointing out that one of them was hidden, or 'shadowed'.

This time, however, it is warning about static method variables shadowing object variables. These are however in two totally different spaces, so can not really shadow. Whilst programmer confusion is still a possibility, what is not possible is code confusion ... at least I don't think so.

class Moo {
int notHidden;

static call() { int notHidden; }
}

should generate an error. In my code, I had to change the names of all of those, chosing one or the other (generally the second). (Olivier, you could now postulate on whether a refactoring tool would be able to do that; I'd be impressed if it could as all the code and all the names are different!)

Whether Java is justified in warning is open to debate. Either way, it is instructive in its very debatability: the programmer has no choice in the debate, he just has the grumble to deal with, and that means fixing the code to turn the grumble off.

So, these compiler checks, Lint, RATS and similar are overriding the programmers' decisions. This is either a good thing or a bad thing, depending; it's a bit like the debate about Boeing versus Airbus and whether the pilot gets to fly a plane or a bus.

Now to opinion. In *general*, I think that driving an Airbus is the way to go, and I'm quite happy for "my teams" to run with high warnings set, because it helps to resolve general bugs. But, I think that what I am saying here is that I would stop short of calling the RATS/Lint approach something that effects *security*. I guess it's a bit like saying that security code is like flying a fighter, and you don't want no darn computer telling you how to do it.

(Of course this analogy falls apart very quickly under real world flying circumstances....)

I think there's a distinction between overriding and commenting on, which you're blurring: The compiler insists you change these. RATS or Lint have no such power.

And you should read a bio of Boyd: It turns out that you almost do want a computer to fly a fighter plane, because given your energy state and that of your opponent, there are a set of moves that will cause you to win, and a set that will cause you to lose. A computer can "easily" be programmed to win a one-on-one fight between two planes. Human creativity is involved in ensuring that your plane starts with the better energy state and perhaps suprise, and dealing with more than one opponent.

Blurring: well, my point here is that when you have a big coding shop, the rule tends towards "no warnings." So if you are using Lint, or RATS or whatever, it makes little difference whether the changes are voluntary or not. The boss tends not to be satisfied until everything is clean. Now, how this applies to RATS in particular I do not know.

Flying analogy: yes, it was in a tail spin from the moment I wrote it; I need a better analogy.

ending note in the above with respect to strcpy and buffer overflows and the recent thread going on in sci.crypt re: same

http://www.garlic.com/~lynn/2004q.html#51

(at the end of the following collection)

http://www.garlic.com/~lynn/subpubkey.html#overflow