On Wed, 2007-07-04 at 12:37 +0200, Jef Driesen wrote:
> Dan Kennedy wrote:
> > On Wed, 2007-07-04 at 09:58 +0200, Jef Driesen wrote:
> >> Igor Tandetnik wrote:
> >>> Mario Figueiredo wrote:
> >>>> I'm a tad bit confused with sqlite3_finalize() usage when the query
> >>>> fails. As it is, I'm assuming it releases resources and I use it in
> >>>> this context:
> >>>>
> >>>> --------------------------------
> >>>> rc = sqlite3_prepare_v2(/* ... */);
> >>>> if (rc != SQLITE_OK)
> >>>> {
> >>>>   sqlite3_finalize(stmt);
> >>>>   /* ... */
> >>>> }
> >>> This doesn't make any sense. If prepare fails, you do not have a valid 
> >>> statement handle to call finalize on.
> >>>
> >> Are you sure about that? The documentation for sqlite3_prepare_v2 says:
> > 
> > Igor is, as usual, correct.
> > 
> > The situation in 3.4.0 is that if sqlite3_prepare() returns other 
> > than SQLITE_OK, you are guaranteed that *ppStmt is set to NULL.
> > You may call sqlite3_finalize() on this if you wish - it's a no-op.
> > 
> > Historically, it may have been that *ppStmt was sometimes left
> > uninitialized if an error occured (hence the "may" in the docs).
> 
> What do you mean with uninitialized? Leaving the pointer unchanged, or 
> pointing to some memory that is already freed or still needs to be 
> freed? This is important if you need to support older versions.
>
> I suppose you mean the first one, but I'm asking anyway just to be sure. 
> In my code, I always initialize pointers to NULL, so this case would not 
> cause any problems at all. The second case is a completely different 
> story of course.

Right, leaving the pointer unchanged.

Dan.



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to