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
[EMAIL PROTECTED]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
