-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23/01/16 13:14, Bart Smissaert wrote: >> I am somewhat confused about what you wrote. > > This has to do with making a .tlb (type library) to access > sqlite3.dll from a VB6 ActiveX dll.
That much was clear. > Sofar I have mapped SQLite int with IDL long ... That is where you confused me. C also has a long type! The C long type will either be the same size as C int, or bigger[1]. Windows has a long legacy, and that is how you ended up in this situation. On 16 bit Windows, int was 16 bits and long 32 bits. On 32 (and 64) bit Windows, int and long are both 32 bits. Because of the 16 bit legacy of Visual Basic, you'll be getting this advice about ints and longs and compatibility. On Win32 where SQLite says "int" it means a signed 32 bit number. Note you can get lucky with mismatches. (I won't bore you with details about promotion to int, caller vs callee cleanup, how little endian helps with the luck). > .. and that is all working fine, except for > sqlite3_compileoption_get. Instead here int or byte works fine. File byte under "lucky" above. sqlite3_compileoption definitely takes a 32 bit integer as its only parameter. If "long" in your idl also maps to a 32 bit integer, then there is something else going on in your diagnosis of "working fine" :-) Sadly you'll need to figure that one out. [1] There are rules about what standards conforming compilers are allowed to do, there is practise over what they actually do, the implementors of systems do various things (often for historical or "compatibility" reasons). This also spills over into ABIs and calling conventions (eg exactly how types of parameters and return values are passed on certain CPU architectures). The list of considerations go on and on. It looks like Keith would be happy to discuss them :-) Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlakJLQACgkQmOOfHg372QS7SACfboJV/o1apKA3q5UInT5sOY6/ NUsAn2UbTS1004P5QnpJGRQcCTASMJaI =LMtI -----END PGP SIGNATURE-----
