> -----Original Message----- > From: Joe Wilson [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 21, 2007 10:34 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Fix for sqlite3.h in version 3.3.10 >
[snip] > > I don't know if this is the right place to post suggestions to the > > SQLite developers, but why don't you do something like > > #define SQLITE_COMPAT_MODE > > and do these things like making SQLITE_TRANSIENT point to real > > function under #ifndef SQLITE_COMPAT_MODE? So the older users can > > compile under SQLITE_COMPAT_MODE and avoid having problems, while > > newly written code can rely on proper, clean code? > > By whose definition of proper code? The ANSI/ISO C and C++ committees, and the standards produced by them. > It would be a lot of effort to "solve" a problem that does not exist. > > >>>> which is diagnosed, though only as a warning, by Sun CC > > It's just a harmless warning produced by the cast when compiled by > a certain overly pedantic C++ compiler. No; the type mismatch is a real problem that can cause real crashes with valid C++ compilers, in the case that C and C++ use different calling conventions. > The proposed typedef offered > by the original poster seems like a reasonable appeasement: > > -#define SQLITE_STATIC ((void(*)(void *))0) > -#define SQLITE_TRANSIENT ((void(*)(void *))-1) > +typedef void (*sqlite3_destructor_type)(void*); > +#define SQLITE_STATIC ((sqlite3_destructor_type)0) > +#define SQLITE_TRANSIENT ((sqlite3_destructor_type)-1) > > But the typedef should not be required. In C++, it is required to give the function pointer the correct type. Any C++ compiler that does not issue a diagnostic for this fails to conform to the C++ standard in this regard (which is not to say that such compilers are uncommon). -- James ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
