This is the mail archive of the libffi-discuss@sourceware.org mailing list for the libffi project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 02/21/2013 05:46 PM, Philip Ashmore wrote:I don't know BSD and my projects won't run on Windows because of design choices, although I'd be happy if someone wanted to port my stuff onto them - I could merge the changes back in.On 21/02/13 15:19, Andrew Haley wrote:On 02/21/2013 01:29 PM, Philip Ashmore wrote:I think a better option would be to tell libffi that the return type is a "non-pod" and let it jump the hoops appropriate for the architecture - am I correct in guessing that my approach isn't portable?
Sort of. There is a standardish C++ ABI known for reasons too arcane to go into as the Itanium C++ ABI http://refspecs.linux-foundation.org/cxxabi-1.83.html
However, putting all this stuff into libffi would be too much IMO. You could think of defining a C++ layer that calls libffi.
if only because libffi doesn't create temporaries for ignored return values. I guess I'm going to have to define a portability layer myself then.
Does/could libffi define macro I could use to determine the c++ ABI?
Only the usual system defines.
The next thing I'd need is a page of docs for all the c++ ABIs for the c ABIs that libffi supports.
If you could reply with such a list that would be great - I'll push ahead with the platform I'm on now - Debian sid amd64.
All the Linuxen use the Itanium C++ ABI. Do you care about Windows and BSD?
Philip
Andrew.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |