December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 12/13/2012 1:38 AM, bearophile wrote: > To spot at compile-time situations like: > > > void main() { > int[5] x; > x[$] = 1; > enum size_t n = 2; > x[$ + n] = 2; > } The compiler does that already. > void main() { > int[] x = new int[5]; > x[$] = 1; // easy > x[x.length] = 1; // idem > enum size_t n = 2; > x[$ + n] = 2; // not too much hard if n is unsigned > x[x.length + n] = 2; // idem > } I just don't see the point in adding flow analysis for that, and it'll ding you at runtime anyway. There are a lot more interesting things that flow analysis can do. |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Thursday, 13 December 2012 at 09:38:18 UTC, bearophile wrote:
>
> From my usages of a lint tool in C, that's able to perform that flow analysis, I have seen that it spots several out of array bound mistakes in the code statically.
>
> [SNIP]
>
> Bye,
> bearophile
I guess you still have to keep in mind that in C, out of bounds access is undefined behavior, and may not error during run-time. This makes out of bounds access a real bane to find C, and tons (excessive?) effort have been expanded to avoid it.
In comparison, D will assert on the first out of bounds access, and you'll immediately see where the problem lies, with no undefined behavior or whatnot.
While I wouldn't disagree that having the compiler do it statically would be a good thing, it's not as critically needed as it would be in C.
I guess I'm just saying the "cost to payback" ratio is not as high as in C.
|
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright: >> void main() { >> int[5] x; >> x[$] = 1; >> enum size_t n = 2; >> x[$ + n] = 2; >> } > > The compiler does that already. I am compiling that little program with dmd -w test.d And I see no compilation errors. See also here, it gives a run-time error: http://dpaste.dzfl.pl/a62a10aa >> void main() { >> int[] x = new int[5]; >> x[$] = 1; // easy >> x[x.length] = 1; // idem >> enum size_t n = 2; >> x[$ + n] = 2; // not too much hard if n is unsigned >> x[x.length + n] = 2; // idem >> } > > I just don't see the point in adding flow analysis for that, I think that doesn't require flow analysis. > and it'll ding you at runtime anyway. This thread is about spotting mistakes at compile-time, that is one of the main advantages of having a static typing in the first place. Bye, bearophile |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 12/13/2012 2:40 AM, bearophile wrote: > Walter Bright: > >>> void main() { >>> int[5] x; >>> x[$] = 1; >>> enum size_t n = 2; >>> x[$ + n] = 2; >>> } >> >> The compiler does that already. > > I am compiling that little program with > > dmd -w test.d > > And I see no compilation errors. Well, it should for those cases. > See also here, it gives a run-time error: > http://dpaste.dzfl.pl/a62a10aa > > >>> void main() { >>> int[] x = new int[5]; >>> x[$] = 1; // easy >>> x[x.length] = 1; // idem >>> enum size_t n = 2; >>> x[$ + n] = 2; // not too much hard if n is unsigned >>> x[x.length + n] = 2; // idem >>> } >> >> I just don't see the point in adding flow analysis for that, > > I think that doesn't require flow analysis. Yeah, it does, unless you care to put in the compiler a long list of special cases. For example, what about $+$, n+$, $+$-$+1, $<<n, etc.? These sort of turn into whack-a-mole games. >> and it'll ding you at runtime anyway. > > This thread is about spotting mistakes at compile-time, that is one of the main > advantages of having a static typing in the first place. Since the bug is caught anyway, such is an extremely low priority because it's got such a low payoff. |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright: > Well, it should for those cases. OK, then I'll split that enhancement request into a bug report. > Yeah, it does, unless you care to put in the compiler a long list of special cases. For example, what about $+$, n+$, $+$-$+1, $<<n, etc.? These sort of turn into whack-a-mole games. I agree that putting lot of similar special cased tests in the compiler is a bad idea (also because code like $+$-$+1 is very uncommon). But can't the already present expression range analysis be used to cover some simple but common enough bugs? > Since the bug is caught anyway, such is an extremely low priority because it's got such a low payoff. If that's true then why aren't you programming in Python? :-) Spotting mistakes at compile time is usually better because the sooner you find bugs, the less problems they cause. And because compile-time tests work on all code paths, while run-time tests only work on the code actively run (so bugs in uncommonly run code paths sometimes do not get caught, and maybe are caught much later by a client running the code). This is one of the main advantages of static typing over unit-testing. Bye, bearophile |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2012-12-13 10:54, Walter Bright wrote: > I just don't see the point in adding flow analysis for that, and it'll > ding you at runtime anyway What about code that is only executed at compile time? -- /Jacob Carlborg |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On 12/13/2012 11:40 AM, bearophile wrote:
> ...
>
> This thread is about spotting mistakes at compile-time, that is one of
> the main advantages of having a static typing in the first place.
> ...
Static code analysis also works when there is no static type checking.
|
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pacoup | import std.stdio; void main() { int[3][2] matrix = [ [1,11,111], [2,22,222] ]; foreach(int[5] row; matrix) //if int[3], there is no error. { foreach(x; row) write(x, " "); writeln(); } } I get runtime error for the above code too. Application error: object.Exception@src/rt/arraycat.d(31): lengths don't match for array copy Why didn't I get a compilation error? All the array sizes are known at compile time. Right? |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Gopan | Gopan: > Why didn't I get a compilation error? All the array sizes are known at compile time. Right? The good Hara and Don have teamed and they have already written a patch and applied it: http://d.puremagic.com/issues/show_bug.cgi?id=6883 So if you are able to compile DMD you are able to test if the new patch works in your case too. Bye, bearophile |
December 13, 2012 Re: No bounds checking for dynamic arrays at compile time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | > So if you are able to compile DMD you are able to test if the new patch works in your case too. The answer was negative: http://d.puremagic.com/issues/show_bug.cgi?id=9150 Bye, bearophile |
Copyright © 1999-2021 by the D Language Foundation