On 3/21/16 7:43 PM, tsbockman wrote:
On Monday, 21 March 2016 at 22:29:46 UTC, Steven Schveighoffer wrote:
It depends on the situation. foo may know that x is going to be short
enough to fit in an int.
The question becomes, if 99% of cases the user knows that he was
converting to a signed value intentionally, and in the remaining 1% of
cases, 99% of those were harmless "errors", then this is going to be
just a nuisance update, and it will fail to be accepted.
My experimentation strongly suggests that your "99.99% false positive"
figure is way, *way* off. This stuff is both:
Maybe, what would be a threshold that people would find acceptable?
1) Harder for people to get right than you think (you can't develop good
intuition about the extent of the problem, unless you spend some time
thoroughly auditing existing code bases specifically looking for this
kind of problem), and also
It matters not to the person who is very aware of the issue and doesn't
write buggy code. His code "breaks" too.
I would estimate that *most* uses of if(arr) in the wild were/are
incorrect. However, in one particular user's code *0* were incorrect,
even though he used it extensively. This kind of problem is what lead to
the change being reverted. I suspect this change would be far more
likely to create more headaches than help.
2) Easier for the compiler to figure out than you think - I was really
surprised at how short the list of problems flagged by the compiler was,
when I tested Lionello Lunesu's work on the current D codebase.
This is highly subjective to whose code you use it on.
The false positive rate would certainly be *much* lower than your
outlandish 10,000 : 1 estimate, given a good compiler implementation.
I wouldn't say it's outlandish given my understanding of the problem.
The question is, does the pain justify the update? I haven't run it
against my code or any code really, but I can see how someone is very
good at making correct uses of the implicit conversion.
With respect to your specific example:
1) The memory limit on a true 32-bit system is 4GiB, not 2GiB. Even with
an OS that reserves some of the address space, as much as 3GiB or 3.5GiB
may be exposed to a user-space process in practice.
Then make it long len = x.length on a 64-bit system.
Only reason I said assume it's 32-bit, is because on 64-bit CPU, using
int is already an error. The architecture wasn't important for the
example.
Huh? The point of mine which you quoted applies specifically to 32-bit
systems. 32-bit array lengths can be greater than `int.max`.
Did you mean to reply to point #3, instead?
You seem to spend a lot of time focusing on 32-bit architecture, which
was not my point at all.
My point is that most arrays and uses are short enough to be handled
with a signed value as the length.
If this is a generic library function, sure, we should handle all
possibilities. This doesn't mean someone's command line utility
processing strings from the argument list should have to worry about
that (as an example). Breaking perfectly good code is something we
should strive against.
-Steve
