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.

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.

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

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.

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

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

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.

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?

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

> 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