www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2672] New: Delegate .funcptr returns wrong type.

reply d-bugmail puremagic.com writes:
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*)


--
Feb 16 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672






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).


--
Mar 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672






-------
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.


--
Mar 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672






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!


--
Mar 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au






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: -------
May 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |





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: -------
May 20 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com
           Platform|x86                         |All
            Version|2.025                       |D1 & D2
         AssignedTo|nobody puremagic.com        |yebblies gmail.com
         OS/Version|Windows                     |All
           Severity|normal                      |major



Same sort of thing as issue 3720.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 29 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2672


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras gmail.com



*** 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: -------
Aug 17 2013