Nicolai Haehnle prefect_ at gmx.net
Tue Sep 3 10:35:01 PDT 2002

Hash: SHA1

On Tuesday 03 September 2002 18:59, Alexander Sabourenkov wrote:
> Hello.
> Nicolai Haehnle wrote:
> > Hash: SHA1
> [ ... ]
> > - From a design POV I think it would be better to use TTF_initialized
> > as a counter of how often TTF_Init() has been called, then only
> > shutting down when the counter reaches 0 again.
> > This way, you'll have to remember whether TTF was init when you started
> > up so you'll know whether to call the Quit function or not.
> SCNR, but what if someone's code calls it too much and the variable
> overflows? I know, I know 2^31 is quite a lot, but all it takes is one
> messed-up condition in while().
>  From code consistency POV it would be much better if TTF_Init() on
> initialized library as well as TTF_Quit on uninitialized crashed the
> program on the spot.
> This would help design one's program more sanely too.

Yes and no. Think WinSock for example. That's another library that needs 
Init and Cleanup calls. They deliberately added reference counting, and for 
a reason: not all the code that is executed during the lifetime of a 
program is written by the programmer of that program. In the WinSock case, 
there might be a utility library (e.g. for the HTTP protocol) that needs to 
access sockets, too. This library needs to work correctly whether the 
program it's used in initializes WinSock or not.
So unless you're doing something that can essentially be done only once 
(which is really rare; SDL_Init could count as such an example), you should 
support some form of reference counting.

About the 2^31: Seriously, if there's an infinite loop that continually 
calls code that calls TTF_Init, then the code in between is likely to 
allocate memory (such as C++ classes). The heap will overflow long before 
2^31 ever becomes an issue (and why don't you use an unsigned int anyway? 
;)). You can still abort() when the reference counter wraps to 0 if you're 
really paranoid.

Version: GnuPG v1.0.7 (GNU/Linux)


More information about the SDL mailing list