lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I had fixed this bug at
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
<> 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.
> -- Lorenzo