logo       

Re: sqlite_free_table bug??: msg#00123

db.sqlite.general

Subject: Re: sqlite_free_table bug??

Ben:

Thanks for clearing that up for me. That just shows how much better an
experienced coder as compare to an elementrary co-op student like me
=). I guess it will take some time before getting up to your level.

Colin



ben.carlyle-LNVqYbe/PQpWk0Htik3J/w@xxxxxxxxxxxxxxxx wrote:
>
> Colin,
>
> It's not possible to change the pointer back to null, nor is advisable.
> It's not possible because you only pass a copy of the pointer into
> sqlite_free_table. You don't pass in the address to the pointer yourself,
> therefore the function couldn't possibly change your copy of the pointer.
> It can only make changes to things your pointer points to. That's why it's
> called a pointer :)
> It's not advisable because that's not the way standard free() works. The
> C-language free() function takes a pointer and returns the space allocated
> at the other end to the memory allocation system. This is exactly what
> sqlite_free_table does. Where there is a standard paradigm built into a
> language, especially where it has to do with something so important as
> memory allocation, it should be followed in every relevant detail.
>
> This is elementary C.
>
> If you're programming C++ you'll notice that delete doesn't change your
> pointer either. If you want to be able to test whether a pointer is valid
> or not, then after a delete, free, or sqlite_free_table you must set the
> pointer back to null. You can change your FreeTable function to the
> following:
>
> > void FreeTable( void ) {
> > sqlite_free_table(result);
> > result = 0;
> > }
>
> Unfortunately this code breaks another basic design paradigm that you'd be
> well advised to follow. That paradigm is "whoever allocates the memory
> should ultumately be the one who cleans it up". You might be better off
> writing your code like this:
>
> int foo(void)
> {
> char **result;
> char *zErrMsg;
> int rc;
> int nrow, ncolumn;
> rc = sqlite_get_table(db, "select * from abc", &nrow, &ncolumn,
> &zErrMsg);
>
> if (rc == SQLITE_OK)
> {
> /* Do processing on the result here */
> sqlite_free_table(result);
> }
> else
> {
> if (zErrMsg)
> {
> printf("Warning: Error in foo() %s\n", zErrMsg);
> free(zErrMsg);
> }
> }
>
> return rc;
> }
>
> While your code avoids a continuous leak by freeing the last result before
> allocating a new one, and while it could be modified with the result = 0
> line to avoid trying to free memory multiple times, you have still
> allocated memory that you will need to explicitly free somewhere else. If
> you don't call FreeTable() again before you're finished processing then
> the results of the last query will sit around in memory until your process
> terminates. With the alternate implimentation in place you are guaranteed
> that the memory will be properly cleaned up after each processing run
> instead of having to wait for the next run to clean up the results of the
> last one.
>
> Benjamin.
>
> Colin Shum <tachyon-oaKApboPmdM9D0CQEJlC7Oqrae++aQT8@xxxxxxxxxxxxxxxx>
> Sent by: tachyon-oaKApboPmdM9D0CQEJlC7Oqrae++aQT8@xxxxxxxxxxxxxxxx
> 20/11/02 18:38
> Please respond to sqlite
>
>
> To: sqlite-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
> cc:
> Subject: Re: [sqlite] sqlite_free_table bug??
>
> When sqlite_free_table frees up the memory block, the pointer passed in
> is not set back to NULL. Thus on the second access of
> sqlite_free_table, it complains with Segmentation fault.
>
> Should really set the pointer back to NULL before exiting.
>
> Colin Shum wrote:
>
> > I am having problems with sqlite_free_table. I tried and cannot call it
> > twice in a row. Is that the same as cant be call with "NULL" pointer?
>
> > char **result;
> > char request_saved[300] = "select * from abc";
> > int nrow = 0;
> > int ncolumn = 0;
> > int rc = 0;
> >
> > void FreeTable( void ) {
> > sqlite_free_table(result);
> > }
> >
> > int foo (void) {
> > FreeTable(result);
> > rc = sqlite_get_table(db, request_saved, &result, &nrow,
> &ncolumn,
> > &zErrMsg);
> >
> > return foo;
> > }
>
>
> To unsubscribe from this group, send an email to:
> sqlite-unsubscribe-VgYJa0VH1e9BDgjK7y7TUQ@xxxxxxxxxxxxxxxx
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/EbFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
sqlite-unsubscribe-VgYJa0VH1e9BDgjK7y7TUQ@xxxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/





<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise