Re: define_c_func/proc and 64-bit return types
- Posted by ghaberek (admin) Aug 01, 2012
- 1273 views
As far as Ansi/Unicode versions of dll routines go, don't we just leave that up to the programmer? Should 64-bit really be any different?
I'm pretty sure, especially on *NIX, that a 64-bit application will attempt to load 64-bit shared libraries, i.e. open_dll("libwhatever.so") will result in a call to e.g. /usr/lib/libwhatever.so on from a 32-bit app and /usr/lib64/libwhatever.so from a 64-bit app. So it isn't as "manual" of a process as calling FunctionA vs FunctionW. (I could be wrong but this is my basic understanding.)
As you say, 32-bit apps need to be able to throw 64-bit ints around, so I would add explicit C_I32, C_I64, C_UI32, C_UI64, etc as well as changing C_INT from #01000004 on 32-bit to #01000008 on 64-bit.
I think this is a great idea. Perhaps we could use some ifdef's to set the generic constants based on bitness:
public constant C_INT32 = #01000004, C_INT64 = #01000008 ifdef EU64 then public constant C_INT = C_INT64 elsedef public constant C_INT = C_INT32 end ifdef
I would also say a 64-bit compiler should generate 64-bit apps; if you want to generate 32-bit apps on a 64-bit box then you should (also) install the 32-bit compiler. If the source has to differ, so be it.
I'm sure the translator could output the code differently based on a flag, and I know with GCC it's just -m32 versus -m64. Perhaps the translator could simply have the same options, and revert to its native bitness by default.
-Greg
