[Issue 2672] New: Delegate .funcptr returns wrong type.

Feb 17, 2009

d-bugmail

Mar 02, 2009

d-bugmail

Mar 02, 2009

Mar 02, 2009

May 19, 2009

May 20, 2009

Jan 30, 2012

Aug 18, 2013

February 17, 2009

[Issue 2672] New: Delegate .funcptr returns wrong type.

Posted by d-bugmail

Permalink

d-bugmail

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=2672

           Summary: Delegate .funcptr returns wrong type.
           Product: D
           Version: 2.025
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid, ice-on-valid-code, rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: dsimcha@yahoo.com


The type of the function pointer returned by delegate.funptr appears to have the same parameter list as the corresponding delegate.  This is incorrect, since a function pointer in this form is useless for actually calling the function in question.  The type of the function pointer should have the pointer to whatever context is relevant added to its parameter list.

import std.stdio;

struct Foo {

    uint function() myFunPtr;
    uint i;

    uint myFun() {
        return i * 2;
    }
}

void main() {
    Foo foo;
    foo.i = 2;
    auto someDelegate = &(foo.myFun);
    foo.myFunPtr = someDelegate.funcptr;  // Works.  Shouldn't.

    // Should be uint function(foo*).  Is uint function().
    writeln(typeof(someDelegate.funcptr).stringof);

    /* Without this line of code, DMD outputs the assembly such that foo's this
     * pointer just happens to be in EAX.  This causes things to work, since
     * DMD passes the this pointer in EAX.  This line makes sure something else
     * gets written to EAX.*/
    uint fooRet = fooPtr();

    // Of course, this doesn't work because no this pointer is getting
    // passed in.
    writeln(foo.myFunPtr());
}

auto fooPtr = &foo;  // Make call indirect so it can't be inlined.

uint foo() {
    return 1;
}


Also, the correct version of this code is rejected.  If I change the type of Foo.myFunPtr to uint function(Foo*), I receive the following errors:

Assertion failure: 'tn->mod & MODinvariant || tn->mod & MODconst' on line 740
in file 'mtype.c'
test7.d(17): Error: cannot implicitly convert expression (*((&
someDelegate+4))) of type uint function() to uint function(Foo*)


--

http://d.puremagic.com/issues/show_bug.cgi?id=2672 ------- Comment #1 from dsimcha@yahoo.com 2009-03-01 19:44 ------- Sane version of this bug report, not posted ridiculously late at night (don't know what I was thinking on my initial post): void delegate(uint) foo; pragma(msg, typeof(foo.funcptr).stringof); // void function(uint) Because of this, you can't use foo.funcptr for calling the underlying function. The correct type would be void function(void*, uint). --

http://d.puremagic.com/issues/show_bug.cgi?id=2672 ------- Comment #2 from kamm-removethis@incasoftware.de 2009-03-02 05:43 ------- Not every delegate can be called as a function. Consider a delegate with the signature 'Struct delegate(int)' whose parameters get passed as a1, hidden, this. If you cast its funcptr to 'Struct function(int a1, void* fthis)' the arguments will be passed as a1, fthis, hidden. Delegates that don't use hidden can be represented as a function with the this pointer as the last argument. I'd argue that funcptr shouldn't have a function type at all. --

http://d.puremagic.com/issues/show_bug.cgi?id=2672 ------- Comment #3 from tomas@famolsen.dk 2009-03-02 08:48 ------- I still think it's silly to throw away function/delegate type compatibility just for the reason of defining parameter passing order at some point in the future. I already posted on the NG about this quite a while back, but my opinion stands! ABI compatibility should be a good thing, in these cases, it's a stick in the wheel! --

http://d.puremagic.com/issues/show_bug.cgi?id=2672 Don <clugdbug@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug@yahoo.com.au --- Comment #4 from Don <clugdbug@yahoo.com.au> 2009-05-19 00:35:27 PDT --- Simple test case for the ICE: ----- auto x = &bar; int bar() { return 1;} int function() y = null; ----- Curiously, it's crashing on the assignment to y! It doesn't happen if you move y above x. Something in the declaration of x is corrupting a data structure (it's related to MODinvariant). I'm still tracking it down. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2672 Don <clugdbug@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|ice-on-valid-code | --- Comment #5 from Don <clugdbug@yahoo.com.au> 2009-05-20 02:18:16 PDT --- I have created bug 3010 to cover the two Internal Compiler Errors mentioned in the comments, since it's a completely unrelated issue. I'm therefore removing ice-on-valid-code from this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2672 yebblies <yebblies@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simen.kjaras@gmail.com --- Comment #7 from yebblies <yebblies@gmail.com> 2013-08-18 16:15:59 EST --- *** Issue 10324 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums