Bug 1069 – No error on type mismatch with varargs

If a vararg function is defined like so: void add( void delegate()[] procs... ) the compiler will not complain when delegates are added without the leading address qualifier, but an error will occur when the delegate is run in some cases. Here is an example: class C { this() { add( fn ); } void fn() { printf( "hello\n" ); } } class Elem { void delegate() proc; Elem next; } Elem first; void add( void delegate()[] procs... ) { foreach( p; procs ) { auto e = new Elem; e.proc = p; e.next = first; first = e; } } void call() { for( Elem e = first; e; e = e.next ) e.proc(); } void main() { auto val = new C; call(); } C:\code\src\d\test>dmd test c:\bin\dmd\bin\..\..\dm\bin\link.exe test,,,user32+kernel32/noi; C:\code\src\d\test>test Access Violation C:\code\src\d\test>

Actually, I think the compiler may be right here. Your code invokes undefined behavior but is otherwise legal and the compiler has every right to successfully compile this into a program that crashes without complaining. Let me explain: What you're seeing is an unfortunate side-effect of the combination of lazy [void delegate()] arguments with the fact that a function name doesn't evaluate to a pointer/delegate to that function but to its return value (i.e. property syntax). Your 'add( fn );' adds an implicit delegate that calls this.dg() (because of property syntax). (It's equivalent to 'add( { fn() } );') Since this implicit delegate refers to the stack frame of the constructor, it's invalid after the constructor returns. Your call() then calls an invalidated delegate, and your program crashes. So as you mentioned, to do what you want you should use 'add( &fn );'. What you didn't realize was that the _reason_ this works is that you're then passing a method delegate instead of an (anonymous) inner function delegate.

[email protected] wrote: > > What you're seeing is an unfortunate side-effect of the combination of lazy > [void delegate()] arguments with the fact that a function name doesn't evaluate > to a pointer/delegate to that function but to its return value (i.e. property > syntax). And here I thought lazy parameters had to be marked 'lazy'. That's annoying. Thanks :-)

Sean Kelly wrote: > [email protected] wrote: >> >> What you're seeing is an unfortunate side-effect of the combination of >> lazy >> [void delegate()] arguments with the fact that a function name doesn't >> evaluate >> to a pointer/delegate to that function but to its return value (i.e. >> property >> syntax). > > And here I thought lazy parameters had to be marked 'lazy'. That's > annoying. Thanks :-) This is the one exception where 'implicit lazy' was kept when the keyword was introduced.

I have expanded the example to show a bit more of the problem an end user can have (sorry I have tango hard-coded, just replace with printf): import tango.io.Stdout; void another() { Stdout("Another one\n"); } class C { this() { add(&fn ); // Needed here add(another); // Not needed here!!!! } void fn() { Stdout( "hello\n" ); } } class Elem { void delegate() proc; Elem next; } Elem first; void add( void delegate()[] procs... ) { foreach( p; procs ) { auto e = new Elem; e.proc = p; e.next = first; first = e; } } void call() { for( Elem e = first; e; e = e.next ) e.proc(); } void main() { auto val = new C; add(another); // Not here! call(); } This code works because by trial and error I have put the "&" in the right places. Can this kind of segfault be avoided be detecting it at the compile stage? Regardless of the answer, I think a diagram (or more details) of what Frits explains in the first reply would help me understand. Thanks.

[email protected] wrote: > I have expanded the example to show a bit more of the problem an end user can > have (sorry I have tango hard-coded, just replace with printf): > [snip] > this() > { > add(&fn ); // Needed here Correct > add(another); // Not needed here!!!! This happens to look like it does what it should, but in reality it still ads a delegate that will be invalid after the constructor returns. That delegate just happens not to reference the stackframe of the constructor, and thus not crash, because all it does is call a free function. It's still undefined behavior, but undefined behavior doesn't necessarily means it'll crash (just that it *may* crash, or worse, and if it does it's your fault). Also, adding a & won't help in this case, as it'll be a function pointer instead of a delegate... > } [snip] > void main() > { > auto val = new C; > add(another); // Not here! Correct, but only because the implicitly formed delegate literal happens not to go out of scope before it's last called. If for instance the module had a 'static ~this()' that would call 'call()' after main ended, it'd be undefined behavior. > call(); > } > > This code works because by trial and error I have put the "&" in the right > places. That's not really the right strategy... Just because it doesn't crash doesn't mean it does what you think it does, or that it won't crash the next time you upgrade/switch compilers (or just change which command-line switches to give to your current one)... > Can this kind of segfault be avoided be detecting it at the compile > stage? At least partially, yes. Google for "escape analysis" (Mostly applied to pointers, which have essentially the same problem when pointing to local variables). It may not possible to catch 100% of all cases (without false positives) though, and it might be a lot of work to implement (not that I'm an expert in this). > Regardless of the answer, I think a diagram (or more details) of what Frits > explains in the first reply would help me understand. Thanks. I'm not really good with diagrams. Just remember: don't use delegates to local functions/delegate literals (including the implicit kind discussed here), pointers to local variables or references to 'scope' objects after the function they were created in returns.

In the context of the example above, here is another flavor: class C { this() { add({Stdout("inline").newline;}) } ... [rest as above] Would this add a delegate that will be invalid after the constructor returns and thus I should avoid doing it? If yes, is this something that would ever be changed in D such that is would be "okay" to do? Thanks.

This is working as designed, although it is bug prone. It might be possible for the compiler to convert a delegate that calls a member function into a delegate to the member function, avoiding this bug.

(In reply to comment #7) > This is working as designed, although it is bug prone. > It might be possible for the compiler to convert a delegate that calls a member > function into a delegate to the member function, avoiding this bug. It was not working as designed, but is now. The current behavior (DMD 2.057) is what Sean expects. This is because implicit conversions to void delegate() have been scrapped. Safe to close now.