[M3devel] function pointers and comparison to nil? mis-typed function pointers?

[Jay]

 > Mistaking the function's real code for a closure is a lot less likely  > than mistaking the function's real code for a trampoline. A trampoline 
What is the danger in "mistaking" "real code" for a "trampoline"?
They are both "real code".
The differences are:
  - trampoline has limited lifetime -- unless it is heap allocated and garbage collected 
    ("real code" also has "limited lifetime", but relatively much longer, if code can be unloaded, which it can be in many environments) 
  - the "real code" of nested functions has a different calling convention than "real code" for non nested functions; it has an extra parameter "somewhere", for the "static link"; in gcc C nested functions on Cygwin/x86, this is in ecx 
 
What do folks think about putting trampolines in executable garbage collected heap?
I think that's inefficient but I'm usually in the minority here regarding the heap being inefficient.
 
One way or another, gcc makes C nested functions fairly portable, except Apple's gcc on Darwin.
Portability of -1 as a marker denoting "not code" is also dubious.
 
I think it stinks either way.
 
Anyone think coming up with "better" per-architecture markers is reasonable?
 
 - Jay



> Date: Mon, 26 May 2008 15:47:53 -0500> From: rodney.bates at wichita.edu> To: m3devel at elegosoft.com> Subject: Re: [M3devel] function pointers and comparison to nil? mis-typed function pointers?> > > > Jay wrote:> > It stinks either way imho.> > The portability is handled, somehow or another, by gcc's support for > > nested functions.> > For example on OpenBSD, they call mprotect to make the trampoline > > executable -- expensive! and leaves a bit of a security hole.> > On Linux you can sometimes mark the .exe as needing an executable stack > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no switch.> > ATL on Windows puts trampolines in the heap and specifically makes them > > executable -- since the heap isn't necessarily executable either.> > The -1 marker is also a bit of a portability problem but I guess in > > practise it works out.> > Using trampolines would make this problem worse, perhaps much worse.> Mistaking the function's real code for a closure is a lot less likely> than mistaking the function's real code for a trampoline. A trampoline> is, after all, always valid machine code on the executing processor.> Not necessarily so for -1.> > > I'd be curious to see how it decodes on various processors.> > > > - Jay> >> -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080526/c3b1bb23/attachment-0002.html>