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] > > ----------------------------------------------------------------------------- > >