[GRASS-dev] GDAL ticket 2537: lib/gis/range.c and lib/gis/find_file.c issues

[Markus Neteler]

On Mon, Aug 25, 2008 at 4:37 PM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>
> Markus Neteler wrote:
>
>> >> Please take a look at
>> >> http://trac.osgeo.org/gdal/ticket/2537
>> >
>> > Someone else needs to be reminded that the solution to memory leaks in
>> > GRASS libraries is not to use those libraries from persistent
>> > applications. The GRASS libraries exist for GRASS, and are designed
>> > for GRASS; whether or not they are useful for anything else isn't
>> > really an issue.
>> >
>> > OTOH, I've committed a fix for the descriptor leak in
>> > lib/proj/datum.c; that actually matters.
>>
>> Here the followup:
>>
>> Comment (by rouault):
>>  Markus, thanks, but as far as I can see, only the leak of FILE* in
>>  lib/proj/datum.c have been applied. There's still a leak of FILE* in
>>  lib/proj/ellipse.c that was addressed by my patch.
>
> Okay, I've fixed that one also.

I'll relay your comments to the other ticket (maybe in future it would be
better to write directly there and add grass-dev at ... in CC there. The
latter I have done). The OSGeo-ID should also work for the GDAL trac.

Here one more comment from there:
rouault wrote:
> I've applied in r15209 my patch, without the part related to
> G_find_file2() where it is not clear if the return value must be freed or
> not.

Markus