RE: FYI, Epoc memory-leak

["Andrew Wheeler" <awheeler@...>]

> > 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...

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... ;-)

-andrew