> >> Having SQLITE_TRANSIENT point to a real function is perhaps a > >> good idea. The problem is such a change would break backwards > >> compatibility of the API. Somebody who compiled against an > >> older SQLite and who drops in a newer DLL with this change will > >> find that their code no longer works. This is something we work > >> very hard to avoid. > > > You could redefine SQLITE_TRANSIENT and still check for the older -1 > > value in the SQLite code (where you've got better control what the > > compiler does).
> 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? 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. 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. ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
