Nick Sabalausky wrote:
3. use of uninitialized variables (no reaching definition)
3. Optimizer detects and reports it. Irrelevant for D, though, because
variables are always initialized. The =void case is rare enough to be
irrelevant.
D variable default-initialization is absolutely no different from your
scenario of a programmer blindly tossing in =0 to shut up a compiler,
*except* that the programmer is never even given the opportunity to do the
right thing. This is *bad*. I *want* variables that haven't meen manually
inited to be statically treated as uninited. C# does this and it works
great.
The difference is the maintenance programmer won't be left puzzling why
there is an explicit assignment to the variable that is never used. The
point to default initialization is consistency in the resulting
behavior. Also, the optimizer will remove nearly all of the default
initializers if they are dead assignments.
Anyhow, I think this issue was beaten to death in the previous thread on
null dereference. I don't wish to divert this thread into rediscussing
it, but rather stick with what other kinds of bug-detecting data flow
analyses there are?
4. dead assignments (assignment of a value to a variable that is never
subsequently used)
4. Dead assignments are automatically detected and removed. I'm not
convinced this should be reported, as it can legitimately happen when
generating source code. Generating false positives annoy the heck out of
users.
I'll agree with you here. But it might be nice to have an option to just
simply report them anyway for when the programmer wants to see if there's
any of these around that he can clean up.
I congenitally dislike optional warnings, as I've pontificated at length
about here before <g>. The problem is it makes for a wishy-washy
definition of the language, and muddies what is legal versus illegal. D
needs to advance the state of the art with clear thinking about what is
legal and what isn't. Warnings and false positives are failures of
language design.
6. array overflows
6. Arrays are solidly covered by a runtime check. There is code in the
optimizer to detect many cases of overflows at compile time, but the code
is currently disabled because the runtime check covers 100% of the cases.
I'm puzzled by why you would prefer to leave this entirely runtime when some
of it can be detected at compile-time. Normally you agree that catching
something at compile-time is better whenever possible. So shouldn't the
array overflows that can be detected at compile-time be detected at
compile-time? I would certainly prefer that.
Because when I implemented it I discovered that a compile time check
rarely (if ever) caught actual bugs, the real problems could only be
caught at runtime. Normally one uses things like foreach which
automatically generate code that won't array overflow.
I generally regard as evil:
1. bugs that have erratic, random, irreproducible symptoms
2. source code that doesn't have an obvious purpose (this includes code
inserted solely to suppress a false positive or warning)
I regard as undesirable:
3. wishy-washy warnings
4. overzealous compiler messages that are more akin to nagging than
finding actual bugs
