On Tue, Jun 24, 2008 at 07:30:28PM +0000, Pierre Habouzit wrote:
> Though for the win32 port where fork is replaced with threads, well,
> it may cause some issues, so I was reluctant wrt them. Of course it's
> unlikely that it will cause problems, but one never knows ;)
OTOH if it's really a problem, we could easily use a custom allocator
in parse-options that registers a pthread_cleanup_push (or whichever
atexit() like pthread use, I'm not really into threads) that would
cleanup this[0]. So maybe just leaking is the simplest way.
As a consequence it makes the restriction about not keeping pointers
to argv during the parse go away, and I frankly don't like this
restriction, it's counterintuitive and very error prone, which arguably
means it's a really bad design.
[0] In fact we may even want to have some kind of
xmalloc_that_is_freed_at_exit that could be used where we
purposely leak things, and cleanse that on atexit() for POSIX
platforms and whatever win32 people like to use in their threads.
It has the nice property to avoid lots of false positives when you
are using valgrind and other memory checkers.
--
·O· Pierre Habouzit
··O madcoder@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpSw5YsCoWag.pgp
Description: PGP signature
