I tried eliminating sqliteInt.h and replacing with explicit declarations
of i64 and u8.   That part worked fine, but func_ext.c also uses
sqliteMalloc
which is also defined in sqliteInt.h which led me down a rabbit hole of
pulling
more and more from sqliteInt.h, and I still can't eliminate the errors and
warnings.  As a reminder, I didn't write the original source code, and I
have
only the vaguest sense of the meaning and need for these functions.  So, if
anyone has any insight on how to accomplish the same goal without using
internal definitions, I'd appreciate hearing about it.

Liam

On 9/11/07, Nuno Lucas <[EMAIL PROTECTED]> wrote:
>
> On 9/10/07, Joe Wilson <[EMAIL PROTECTED]> wrote:
> > --- Liam Healy <[EMAIL PROTECTED]> wrote:
> > > Thanks for the tip Joe.  With sqlite3.h included, I can eliminate os.hand
> > > vdbeInt.h, but not sqliteInt.h.  Apparently sqliteInt.h is not
> included by
> > > sqlite3.h, and there are typedefs there that are needed.
> >
> > It would be nice if people could use the extension functions with
> > the amalgamation, consisting of just sqlite3.h and sqlite3.c.
> > If you use sqliteInt.h, they can't do that.
> >
> > Why not just repeat the typdefs for u8, etc, in your module?
>
> Don't know current compiler standard compliance, but maybe including
> the "new" <stdint.h> header file and using uint8_t, uint16_t, etc.
> could be better yet (instead of every library having it's own typedef
> section for basic types).
>
>
> Regards,
> ~Nuno Lucas
>
>
> -----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
>
> -----------------------------------------------------------------------------
>
>

Reply via email to