On Monday, 28 May 2018 at 21:05:00 UTC, Dr.No wrote:
On Monday, 28 May 2018 at 02:10:48 UTC, sarn wrote:
On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote:
What's likely the reason of the crash? mismatch between D and
C memory alignment?
From an ABI point of view, the raw pointers won't care about
the memory structure they point to. The function call is the
only thing that depends on the binary interface.
If you translate the code into C, does it work?
Yep, the C version work just fine.
This sort of issue is most often caused by a mistake in the
bindings: incorrect calling convention, wrong parameter/return
types, incorrect number of parameters, etc. In this case, if we
look in pdf.h we can see it includes "dllbegin.inc'. There,
you'll find the following:
#if defined _WIN32
#define CALLTYPE __stdcall
#else
#define CALLTYPE
#endif
#ifdef __cplusplus
#define CAPI(type) extern "C" DLL_PUBLIC type CALLTYPE
#else
#define CAPI(type) DLL_PUBLIC type CALLTYPE
#endif
https://github.com/clowder/wkhtmltopdf/blob/master/src/lib/dllbegin.inc#L43
In pdf.h, that CAPI macro is used in every function declaration.
That means that on Windows, all of the functions have the
__stdcall calling convention (which, in D, would be
extern(Windows)) and the standard cdecl calling convetion on
other platforms (extern(C) in D).
In the D binding, we see that all of the functions are declared
as extern(C) (line 4 of pdf.d). That means on Windows, the
calling convention on the D side is incorrect.
What you need to do is to change that extern(C) delcaration in
pdf.d to extern(System). This will translate to extern(Windows)
on Windows and extern(C) elsewhere to match the C headers.
