RE: FYI, Epoc memory-leak

[Reuben Thomas <rrt@...>]

> > > yah, good point.  I haven't dug into CloseSTDLIB(), but the docs state
> that
> > > it deallocates the DLL's "thread-local storage" structure, _reent.
>
> > In that case, it sounds as though I ought to do the following:
> >
> > 1. Say that C++ users of the Lua DLL *must* call CloseSTDLIB() (if they
> use
> > any I/O).
> >
> > 2. Make the OPX call CloseSTDLIB() just after calling lua_close(), and
> > require OPL programmers to call LuaClose:() (the OPL equivalent).
> >
> > 3. C programmers (i.e. using STDLIB) needn't worry about it.
> >
> > Does this sound right?
>
> Kinda.  Something tells me pretty-much on the same page, but, to clarify,
> the delineation isn't between C and C++, but between executables (.exe's)
> and EIKON apps (.app's).  Given that pretty-much all apps will be coded in
> C++ (though executables that use STDLIB may or may not be coded in C++)
> you've probably covered all your bases.  But regardless, we muddle the issue
> by making any delineation at all: it confuses the issue for inaccurate
> rules-of-thumb.  So I'd just document the necessary call to CloseSTDLIB(),
> maybe hint about cases where the calls aren't absolutely necessary, and then
> refer to the "porting" html-page in the EPOC C++ SDK online help.  Those
> developers that want to better understand EPOC's STDLIB (and hence how to
> cut corners) will then know where to go to look...

OK, I'll make the distinction between EXEs and APPs instead. But you seem to
be saying I can change my list to:

1. C/C++ programs must call CloseSTDLIB() if they do any Lua I/O.

2. OPL programmers must call LuaClose:() (and I have to make the OPX routine
call CloseSTDLIB()).

The reason I was a bit confused is that if you're using STDLIB in your C/C++
program, then *it* will call CloseSTDLIB for you on exit anyway. But if you
can safely call CloseSTDLIB() more than once, I might as well just give the
simpler (and safer) rules above.

> My apologies if I'm making a mountain out of a molehill: I develop
> software-libraries for 3rd-party developers by trade, and have learned to
> follow the "road most anal" when it comes to documentation... ;-)

I'm with you all the way on that one. Thanks for taking the trouble to make
it clear.

-- 
http://sc3d.org/rrt/ | perfect, a.  unsatirizable