Re: wrapping C code - my exercise in incompetence.
- Posted by jimcbrown (admin) Jan 12, 2016
- 2231 views
Correct. The ifdef BITS32 in his code prevents the bug on 32-bit platforms, so I can see how it can seem to be ifdef-related.
Could you explain please? When I extract the portion between ifdefs, I still don't understand where I have to correct the code because I didn't catch the logic behind ifdef management.
In my case, Eu 4.1 on x86-64, the interpreter should see
case C_BOOL, C_INT then -- 32-bit signed (#01000004) lg += 4 case C_DWORD, C_UINT then -- 32-bit unsigned (#02000004) lg += 4 case C_DWORDLONG, C_LONGLONG then -- 64-bit integer (#03000002) lg += 8 case C_LONG, C_HRESULT then -- 64-bit signed (#01000008) lg += 8 case C_ULONG, C_SIZE_T then -- 64-bit unsigned (#02000008) lg += 8 case C_POINTER, C_HANDLE, C_HWND, C_LPARAM, C_WPARAM then -- 64-bit pointer (#03000001) lg += 8
On 64bit, C_HANDLE is defined as a C_LONGLONG (#03000002), not as a C_POINTER (#03000001)
See http://scm.openeuphoria.org/hg/euphoria/file/16462e686646/include/std/dll.e#l68 and http://scm.openeuphoria.org/hg/euphoria/file/16462e686646/include/std/dll.e#l64
unrelated to the above, to future proof code a little: instead of checking for EU4_1,
I wonder if that should instead be EU4
euphoria 4.0 will be handled already by the ifdef EU4_0 and at some future time when EU4_2 is defined, the code presumably could still work as expected.
Sounds reasonable.
Do I have to understand that on a 64-bit system, both BITS32 and BITS64 are defined ?
Nope.
