--- James Dennett <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Joe Wilson [mailto:[EMAIL PROTECTED] > > 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.
Please cite the passage in either the C or C++ standards. The proposed expression ((sqlite3_destructor_type)-1) is equivalent to ((void(*)(void *))-1). They are interchangable. > > 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. Please show the source code that produces this Sun C++ compiler warning with the exact text of the warning. > 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). You're making the assumption that Sun's C++ compiler warning is correct in this case. Should Sun change their definitions of the following as well? #define SIG_IGN (void(*)(int))1 #define SIG_ERR (void(*)(int))-1 Such C code is grandfathered in C++. If it wasn't you wouldn't be able to do any UNIX systems programming in C++. ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
