> No, this is a list of function pointers Ah, I see now. This all a bit alien for a simple VBA coder like me. Thanks for clearing that up and I suppose I got it right now then.
RBS -----Original Message----- From: Martin Jenkins [mailto:[EMAIL PROTECTED] Sent: 25 February 2007 09:46 To: sqlite-users@sqlite.org Subject: Re: [sqlite] compiling with VC++ RB Smissaert wrote: > OK, I understand better now. This though doesn't seem quite right to > me: > > 0, //sqlite3_libversion, > > It looks sqlite3_libversion should be a string. No, this is a list of function pointers. C has no notion of the *name* of the function, only its address. Functions are called by writing that address with a following "()". If you used a string containing the name of the function you end up trying to execute ASCII text. This is never going to work, though it is the basis of the buffer overflow technique that our friends the virus writers use. :( > Would it matter that I make it 0, rather than say ""? If it should be > an empty string then how would I do that in C? You're confusing 0 the string terminator with 0 the NULL pointer. "" is an empty string but it has an address and at that address is a 0 which (as defined by the C standard) terminates the string. 0 in a pointer context tells the compiler to generate a special (NULL) pointer which cannot be dereferenced. The C standard defines that 0 in source code means NULL pointer but the implementation value is not defined. That is, a NULL pointer may or may not be numerically 0 in the binary object but usually is. It matters because Dr Hipp has set it up that way. Wherever it is that these functions are dispatched, there will be a NULL pointer check. If the pointer is NULL then no attempt is made to run the function. As I said above, "" has an address so it will pass the not NULL test and an attempt will be made to execute whatever that string pointer points at (0 followed by ???) and...crash. The real trouble with this is that execution might proceed for a while or even end up at a random but legitimate location within the program code, meaning the crash occurs some time later and far away from the actual bug location. M$ have something called DEP in XP which is meant to prevent this kind of thing, but it needs a reasonably up to date CPU. We might be in danger of getting coughed <off topic> soon. ;) Martin ---------------------------------------------------------------------------- - To unsubscribe, send email to [EMAIL PROTECTED] ---------------------------------------------------------------------------- - ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
