www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - Can't declare extern(C) fp in function body

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
DMD 0.109, Linux

The following program fails on line 7 with the error:
	found 'extern' instead of statement


 import std.stdio;
  
 extern(C) void foo(int i,char c) { writef("%d, %s\n", i,c); }
 extern(C) void function(int,char) global_fp = &foo;
  
 void main() {
   extern(C) void function(int,char) local_fp = &foo;
  
   global_fp(1,'a');
   local_fp(2,'b');
 }
Dec 14 2004
next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 DMD 0.109, Linux
 
 The following program fails on line 7 with the error:
     found 'extern' instead of statement
 

 import std.stdio;
  
 extern(C) void foo(int i,char c) { writef("%d, %s\n", i,c); }
 extern(C) void function(int,char) global_fp = &foo;
  
 void main() {
   extern(C) void function(int,char) local_fp = &foo;
  
   global_fp(1,'a');
   local_fp(2,'b');
 }


 
 



Yeah, I was going to mention that.  I tried to do that too and it didn't 
work...

I think the problem is that it doesn't make sense to declare a function 
extern(C) inside another function, thus it seems D refuses to permit any 
type of extern(C) reference there.  But this keeps the programmer from 
being able to declare a function variable extern(C), which appears to be 
a severe limitation.

So what to do?  It works in a class, so should it also work in a 
function?  I'm not sure what the answer to that is.  But I did find a 
bit of a cheat that works around the problem.  Try:



















Alias will work too.  Kind of strange, but perhaps it a safer way of 
achieving the same goal, anyway.  Gotta love typedef and alias! :-)

-John
Dec 14 2004
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
John Reimer wrote:

 I think the problem is that it doesn't make sense to declare a function 
 extern(C) inside another function, thus it seems D refuses to permit any 
 type of extern(C) reference there.  But this keeps the programmer from 
 being able to declare a function variable extern(C), which appears to be 
 a severe limitation.


I could imagine a scenario where you pass a pointer to a nested function 
(or even an anonymous function!) to a C library.  I'm pretty sure that 
extern(C) says things about the calling convention (not just the 
mangling) and so you'd need extern(C) in that case.  We probably want to 
be able to do:


 extern(C) void RegisterCallback(extern(C) int function() foo);
 void main() {
   RegisterCallback(extern(C) function int() { return 0; });
 }


But right now that code breaks terribly.
Dec 14 2004
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 John Reimer wrote:
 

 I think the problem is that it doesn't make sense to declare a 
 function extern(C) inside another function, thus it seems D refuses to 
 permit any type of extern(C) reference there.  But this keeps the 
 programmer from being able to declare a function variable extern(C), 
 which appears to be a severe limitation.


 
 
 I could imagine a scenario where you pass a pointer to a nested function 
 (or even an anonymous function!) to a C library.  I'm pretty sure that 
 extern(C) says things about the calling convention (not just the 
 mangling) and so you'd need extern(C) in that case.  We probably want to 
 be able to do:


Yes, I belive calling convention is different for extern(C), ie order 
the arguments are pushed/pulled off the stack.


 extern(C) void RegisterCallback(extern(C) int function() foo);
 void main() {
   RegisterCallback(extern(C) function int() { return 0; });
 }


 
 
 But right now that code breaks terribly.
 


Okay, that sounds reasonable.  You also want extern(C) to be available 
for function literals as well.  Referring to my example, doesn't the 
function type declaration with extern(C) fix this problem then?  The use 
of alias or typedef cleans up the lenghthy declarations as a bonus.

Later,

John
Dec 14 2004
prev sibling next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 John Reimer wrote:
 

 I think the problem is that it doesn't make sense to declare a 
 function extern(C) inside another function, thus it seems D refuses to 
 permit any type of extern(C) reference there.  But this keeps the 
 programmer from being able to declare a function variable extern(C), 
 which appears to be a severe limitation.


 
 
 I could imagine a scenario where you pass a pointer to a nested function 
 (or even an anonymous function!) to a C library.  I'm pretty sure that 
 extern(C) says things about the calling convention (not just the 
 mangling) and so you'd need extern(C) in that case.  We probably want to 
 be able to do:
 

 extern(C) void RegisterCallback(extern(C) int function() foo);
 void main() {
   RegisterCallback(extern(C) function int() { return 0; });
 }


 
 
 But right now that code breaks terribly.
 


 From further testing, I see now that even with typdef or aliasing, one 
can't do an extern(C) function literal. Interesting.  While that's a 
limitation, I don't think it's a very significant one since it just 
means that you have to declare a separate local function.

Later,

John
Dec 14 2004
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 John Reimer wrote:
 

 I think the problem is that it doesn't make sense to declare a 
 function extern(C) inside another function, thus it seems D refuses to 
 permit any type of extern(C) reference there.  But this keeps the 
 programmer from being able to declare a function variable extern(C), 
 which appears to be a severe limitation.


 
 
 I could imagine a scenario where you pass a pointer to a nested function 
 (or even an anonymous function!) to a C library.  I'm pretty sure that 
 extern(C) says things about the calling convention (not just the 
 mangling) and so you'd need extern(C) in that case.  We probably want to 
 be able to do:
 

 extern(C) void RegisterCallback(extern(C) int function() foo);
 void main() {
   RegisterCallback(extern(C) function int() { return 0; });
 }


 
 
 But right now that code breaks terribly.
 


You won't believe this (or maybe you will), but the above is possible 
with some manipulation.  D seems to be full of surprises.  I tried the 
following and it worked:
















Output:

100

Later,

John
Dec 14 2004
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
John Reimer wrote:

 Russ Lewis wrote:
 

 John Reimer wrote:


 I think the problem is that it doesn't make sense to declare a 
 function extern(C) inside another function, thus it seems D refuses 
 to permit any type of extern(C) reference there.  But this keeps the 
 programmer from being able to declare a function variable extern(C), 
 which appears to be a severe limitation.




 I could imagine a scenario where you pass a pointer to a nested 
 function (or even an anonymous function!) to a C library.  I'm pretty 
 sure that extern(C) says things about the calling convention (not just 
 the mangling) and so you'd need extern(C) in that case.  We probably 
 want to be able to do:


 extern(C) void RegisterCallback(extern(C) int function() foo);
 void main() {
   RegisterCallback(extern(C) function int() { return 0; });
 }




 But right now that code breaks terribly.


 
 You won't believe this (or maybe you will), but the above is possible 
 with some manipulation.  D seems to be full of surprises.  I tried the 
 following and it worked:
 














 
 Output:
 
 100
 
 Later,
 
 John


Now that I think about this a little more, access to function literals 
like this is indeed useful and important.  This was one problem that I 
had been trying to solve awhile ago in one of my projects.  It had more 
to do with extern(C) local functions than function literals, but the 
idea was the same.  The fact that an extern(C) function can be passed 
like so is a great asset!

Later,

John
Dec 14 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I'm pretty sure that the code you wrote below exposes another bug in the 
compiler.  That cast would certainly be broken in any architecture where 
the C and D calling conventions were different.

John Reimer wrote:

 Russ Lewis wrote:
 

 John Reimer wrote:


 I think the problem is that it doesn't make sense to declare a 
 function extern(C) inside another function, thus it seems D refuses 
 to permit any type of extern(C) reference there.  But this keeps the 
 programmer from being able to declare a function variable extern(C), 
 which appears to be a severe limitation.




 I could imagine a scenario where you pass a pointer to a nested 
 function (or even an anonymous function!) to a C library.  I'm pretty 
 sure that extern(C) says things about the calling convention (not just 
 the mangling) and so you'd need extern(C) in that case.  We probably 
 want to be able to do:


 extern(C) void RegisterCallback(extern(C) int function() foo);
 void main() {
   RegisterCallback(extern(C) function int() { return 0; });
 }




 But right now that code breaks terribly.


 
 You won't believe this (or maybe you will), but the above is possible 
 with some manipulation.  D seems to be full of surprises.  I tried the 
 following and it worked:
 














 
 Output:
 
 100
 
 Later,
 
 John
Dec 14 2004
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 I'm pretty sure that the code you wrote below exposes another bug in the 
 compiler.  That cast would certainly be broken in any architecture where 
 the C and D calling conventions were different.
 


But, I believe they are different on the pc platform.  Doesn't the cast 
just force the calling convention expected by the argument?

I realize that you are referring to the function literal's status as an 
extern(D) type function as declared. Is it not possible for that to be 
changed by casting?  I don't know enough about the low level details to 
comment further.  Perhaps Walter will clarify?

Later,

John
Dec 14 2004
prev sibling next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 I'm pretty sure that the code you wrote below exposes another bug in the 
 compiler.  That cast would certainly be broken in any architecture where 
 the C and D calling conventions were different.
 


Okay, I'm doing a few more tests.  The bug probably doesn't show because 
the function doesn't take any arguments.  Calling convention issues 
probably surface once arguments are included.  I'll give it a go.

Later,

John
Dec 14 2004
prev sibling next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 I'm pretty sure that the code you wrote below exposes another bug in the 
 compiler.  That cast would certainly be broken in any architecture where 
 the C and D calling conventions were different.
 


Ah yes, you are correct to question this one... Obviously I was getting 
excited about the possibilities without thinking the problem through 
clearly... just being hopeful.

Example:


















Output:

Test: 4, 2, 4202512
Return Value: 4202518
Error: Access Violation

In this case "func" is an extern(D) type and "f" is extern(C).

Now the question is: is this example equivalent to casting a function 
literal?  I'm not sure yet.

I was hoping that the function literal could be coerced in its 
definition by the cast to a different calling convention.

- John
Dec 14 2004
prev sibling parent John Reimer <brk_6502 yahoo.com> writes:
Russ Lewis wrote:

 I'm pretty sure that the code you wrote below exposes another bug in the 
 compiler.  That cast would certainly be broken in any architecture where 
 the C and D calling conventions were different.
 


And finally a proper example that demonstrates why what Russ said here 
is true:















Output:

Test Function literal: 4, 2, 4202564
Return value: 4202570
Error: Access Violation

"Can't declare extern(C) fp in function body" is a valid complaint. 
Fixing this in D should improve interfacing with external C code.

- John
Dec 14 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
This was mentioned in passing in this thread, but I thought I would mark 
it explicitly: at least in the context of a cast, I can't declare the type
	extern(C) int function()

The following module won't compile, but I'm pretty sure that it should. 
  (Can we add this to DStress?):


 extern(C) void *wglGetProcAddress(char*);
 extern(C) int function() glFunctionFoo;
  
 static this() {
   glFunctionFoo = cast(extern(C) int function())
                       wglGetProcAddress("glFunctionFoo");
 }


Second, here's an example which (correctly) fails because I don't add 
the extern(C) modifier.  This would be good to add to DStress as expfail:


 extern(C) void *wglGetProcAddress(char*);
 extern(C) int function() glFunctionFoo;
  
 static this() {
   glFunctionFoo = cast(int function())
                       wglGetProcAddress("glFunctionFoo");
 }
Dec 14 2004
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Added to DStress as
http://svn.kuehne.cn/dstress/nocompile/extern_06.d
http://svn.kuehne.cn/dstress/compile/extern_07.d

Thomas

Russ Lewis schrieb am Tue, 14 Dec 2004 20:23:47 -0700:

 This was mentioned in passing in this thread, but I thought I would mark 
 it explicitly: at least in the context of a cast, I can't declare the type
 	extern(C) int function()

 The following module won't compile, but I'm pretty sure that it should. 
   (Can we add this to DStress?):


 extern(C) void *wglGetProcAddress(char*);
 extern(C) int function() glFunctionFoo;
  
 static this() {
   glFunctionFoo = cast(extern(C) int function())
                       wglGetProcAddress("glFunctionFoo");
 }


 Second, here's an example which (correctly) fails because I don't add 
 the extern(C) modifier.  This would be good to add to DStress as expfail:


 extern(C) void *wglGetProcAddress(char*);
 extern(C) int function() glFunctionFoo;
  
 static this() {
   glFunctionFoo = cast(int function())
                       wglGetProcAddress("glFunctionFoo");
 }




-----BEGIN PGP SIGNATURE-----

iD8DBQFBwHe03w+/yD4P9tIRAk0OAJ0e+R9x8FJRZ5SJofA4yEXtdoDMYgCgvJQR
TaV+pFaIj1jAWhHStB1lQMA=
=6K9A
-----END PGP SIGNATURE-----
Dec 15 2004