Re: Small issue with lfs compiled under mingw

[Fabio Mascarenhas <mascarenhas@...>]

I had fixed this bug at http://github.com/keplerproject/luafilesystem
a while ago, but never got around to release a version 1.5.1, probably
because it was so minor; it cannot cause a memory leak, as the
"closed" directory is actually closed, and its resources freed, when
the object is collected (or you call :close a second time).

Anyway, LFS has got some contributed code lately that merits a new
release, I will do it ASAP.

--
Fabio Mascarenhas


On Tue, Aug 9, 2011 at 2:58 AM, Lorenzo Donati
<lorenzodonatibz@interfree.it> wrote:
> Sorry to bother the list again.
>
> Just to ask whether this is the right place to ask for lfs support, since I
> had little feedback till now.
>
> I'd like to avoid cross posting, so I'm asking this before trying with the
> Kepler project mailing list (BTW would that be the right place to ask?).
>
> Since almost no one seemed concerned, maybe the issue I found is really a
> glitch with no harmful consequences, but I'm a bit paranoid and I'd really
> appreciate a definitive word about it, especially to rule out a possible
> memory leak when trying to close a dir object (I haven't the C expertise to
> judge by myself just reading the code).
>
> For what I understand it is not something only related to my
> system/toolchain, but could affect all Win32 systems: analyzing the source
> of lsf.c it seems that d->hFile is initialized to 0L in dir_iter_factory and
> assigned an active handle only after the first call to dir_iter, so
> dir_close will always get a 0L for d->hFile if no iteration has taken place
> yet, and therefore won't update d->closed to 1 in this case.
>
> TIA
> -- Lorenzo
>
>