[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: FYI, Epoc memory-leak
- From: Reuben Thomas <rrt@...>
- Date: Tue, 8 May 2001 12:05:47 +0100 (BST)
> > > yah, good point. I haven't dug into CloseSTDLIB(), but the docs state
> > > 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
> > 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
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
http://sc3d.org/rrt/ | perfect, a. unsatirizable