Calling convention [Was: Trouble with lua_newstate() syntax]

[Bruno Silva <brunos@...>]

Large projects typically have mixed calling conventions depending on where
their libraries come from.

Say you have a lua DLL compiled with _stdcall, which is shared between
multiple projects and teams. If your client project uses _fastcall as
default, for instance, you have to have the lua functions (and function
pointers!) tagged with the _stdcall calling convention for the correct code
to be generated, even though you set the compiler calling convention switch
globally.

I am not advocating one calling convention over any other, but it would be
nice to have a preprocessor symbol preceding every exported lua function
prototype, to help put up with these environment and project dependent
compiler optimizations.

I modify my lua.h, luadebug.h, lualib.h and luaauxlib.h with something like
this:

	typedef void (LUAEXPORT *lua_CFunction) (lua_State *L);
	lua_State     * LUAEXPORT lua_newstate (const char *s, ...);

And then let LUAEXPORT be defined externally.

This is definitely in the "would be nice to have at least for windows
programmers" category, and I know how making the headers fully configurable
for all environments can get so messy. But it's nice not to have to touch
the distribution source code to use it.

Bruno Silva
RPG, Adventure and Technology Games Group
Microsoft Corp.

-----Original Message-----
From: Dave Bollinger [mailto:DBollinger@compuserve.com]
Sent: Monday, June 19, 2000 5:39 PM
To: Multiple recipients of list
Subject: Re: Trouble with lua_newstate() syntax


  [[ oops, did not mean to send previous message as it is unfinished and
contains an error ]]

  Delphi can actually use cdecl calls if you specify as such in the import
unit, though VB requires stdcall.  And the stdcall convention will support
varargs, though it changes "who" is responsible for the stack cleanup. 
(though I don't believe that either Delphi or VB has native syntax for
calling a vararg function)

  I guess my point was simply that the more "typical" way of coding a truly
generic DLL is to avoid varargs where possible, and definately use the
stdcall convention.  It's just easier to provide multi-language support
where that's the case.  And that seems like a worthy goal for an embedded
scripting language - to be as platform-friendly/platform-generic as
possible.

  Anyway, like I said there are ways around it, I just wanted to mention
it.

 >> In fact to use the stdcall convention you have to edit all the 
 >> declaration and implementation of exported functions.

  ..unless your compiler has a global switch for default calling
convention.  :-)

  Cheers,

  Dave