> 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.
This type library is made by compiling (with midl) an .idl source file.
In this .idl file I need to map the SQLite data types with IDL data types.
Sofar I have mapped SQLite int with IDL long and that is all working fine,
except for sqlite3_compileoption_get.
Instead here int or byte works fine.
I am not an expert in IDL, but I understand that int should be avoided as
an IDL data type as it may not match properly
with C.
So, what is different in the int argment in sqlite3_compileoption_get that
makes long as an IDL data type fail?
And how could I have anticipated that?
And also should this somehow be in the documentation, that is the
documentation in:

https://www.sqlite.org/c3ref/funclist.html

Hope this makes it a bit clearer.


RBS



On Sat, Jan 23, 2016 at 8:55 PM, Roger Binns <rogerb at rogerbinns.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 23/01/16 11:41, Bart Smissaert wrote:
> > My question is how could I have foreseen this problem, so how could
> > I have known that using long is no good here?
>
> I am somewhat confused about what you wrote.  SQLite provides a C
> level api.  You can ignore the types and put in alternatives.
> Depending on byte order, calling conventions, what the C types
> actually mapped to, sizes of types etc it may work when wrong anyway,
> or you could get seriously messed up problems.  IOW you are getting
> lucky using long instead of int.
>
> > Not from the documentation of sqlite3_compileoption_get:
> > https://www.sqlite.org/c3ref/compileoption_get.html
>
> Could you explain all this again?  As written you seem to want to know
> the places where you can ignore the types the C SQLite uses, and
> substitute others you feel like using instead.
>
> The answer is don't do that, if you do do that you'll have an
> experience anywhere from getting lucky to subtly corrupting things to
> crashes.
>
> > Could I see it from the sqlite3.c source? Should this be documented
> > somehow better?
>
> The function name, argument and return types in C are generally
> referred to as its prototype.  These are usually listed in header
> files (extension of .h) and if you look in the SQLite distribution
> you'll find a sqlite3.h that contains them all.
>
> However that file is over 400kb long (there are a lot of comments and
> supporting information).  The SQLite C function doc is more accessible
> and includes the same information:
>
>   https://www.sqlite.org/c3ref/funclist.html
>
> Roger
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iEYEARECAAYFAlaj6NgACgkQmOOfHg372QTEtgCgxcMpQxsQDEfKqcUkCBS+Mvhw
> tuAAnRg10CKwOUmJQgvqpPGTwhK5+KbE
> =BZ6P
> -----END PGP SIGNATURE-----
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

Reply via email to