List:General Discussion« Previous MessageNext Message »
From:Dan Nelson Date:December 23 2004 7:14pm
Subject:Re: mysql_fetch_lengths()
View as plain text  
In the last episode (Dec 23), Teresa A Narvaez said:
> > Dan wrote:
> > In the last episode (Dec 23), Teresa A Narvaez said:
> > > We were running mysql 3.22.30 on an Tru 64 Alpha server OSF 4.0F. 
> > > We recently upgraded to mysql 3.23.58 on the same server.
> > >
> > > In the code fragment below, there is a memory leak at line 8
> > > because mysql_fetch_lenghts returns an array of unsigned long
> > > integers representing the size of each column.  So, has the retun
> > > value of mysql_fetch_lengths() been the same for mysql 3.22.30
> > > and 3.23.58?
> > 
> > The memory allocated at line 8 is freed at line 15.  In fact, it's
> > never used at all.  The array returned by mysql_fetch_lengths is an
> > internal array that is freed by mysql_free_result(); you don't need
> > to allocate it or free it.
>
> Thank you for the response.  I completely agree with your response. 
> The reason why I asked this question is because I remember seeing
> len(unsigned long *lengths;) dynamically allocated in the MYSQL
> manual some time ago(when I was running mysql 3.23.30).  So, I wonder
> if there was a change in the return value of mysql_fetch_lenghts() in
> mysql 3.23.58. Otherwise, I made a mistake in dynamically allocating
> memory for len.  I must have misunderstood.

I don't think it has ever required the user to malloc or free the
lengths array.  I checked back as far as 3.20.32, and the
mysql_fetch_lengths function is identical to 3.23.58, except for the
change from int* to long*.

-- 
	Dan Nelson
	dnelson@stripped
Thread
mysql_fetch_lengths()Teresa A Narvaez23 Dec
  • Re: mysql_fetch_lengths()Dan Nelson23 Dec
Re: mysql_fetch_lengths()Teresa A Narvaez23 Dec
  • Re: mysql_fetch_lengths()Dan Nelson23 Dec
Re: mysql_fetch_lengths()Teresa A Narvaez23 Dec