[RFC] argz_create_sep problem

[Gary V. Vaughan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dalibor Topic wrote:
| hi gary,
|
| Gary V.Vaughan wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|>
|> On 21 Mar 2004, at 16:37, Dalibor Topic wrote:
|>
|>> Well, ping :)
|>
|>
|>
|> 64 bytes from address@hidden: icmp_seq=0 ttl=64
|> time=1008185.233 ms
|> 64 bytes from address@hidden: icmp_seq=1 ttl=64
|> time=236702.212 ms
|> - --- localhost ping statistics ---
|> 2 packets transmitted, 2 packets received, 0% packet loss
|> round-trip min/avg/max = 236702.212/622433.722/1008185.233 ms
|
|
| rotfl!
|
|>> I just wanted to check if someone could review this patch against
|>> 1.5.2, and check it in, eventually.
|>
|>
|>
|> It is probably safer to just use all libtool's argz functions
|> exclusively.  I'll
|> commit something along those lines when I get my libtool archive
|> mirror working
|> properly :-)

I started work on this, and it occurred to me that libltdl needs to be
careful to track which variables hold memory allocated by system malloc
(eg argz_create_sep, strdup) and which hold memory allocated by the user
supplied malloc function (eg lt_dladdsearchdir) so that each memory block
is eventually released by a matching free.

All well and good, but then we end up with functions that use system
mallocating functions, but need to return lt_dlmalloc managed memory (eg
lt_dlpath_insertdir), so we have to start copying memory blocks between
different managers, and being careful to free with the correct function
all the while.  The pain of wrapping, say strdup, just to use the clients
mallocator, or the pain of tracking any memory that we got from system
strdup so that we can free it properly later seems unneccessary to me.

That being the case, and since libltdl is a near system level library from
the users' perspective I don't think there is anything to gain from the
error prone problem of keeping track of what vars hold memory from what
allocator.  If a client of libltdl has a separate allocator, then it
already has to solve this very same problem so libltdl is not providing any
convenience by trying to abstract the difference away.

Further, what exactly is the point of lt_dlmalloc et. al. anyway?  Do clients
like kaffe really want to let libltdl loose on their special mallocators? I
suspect not.

CONCLUSION
**********

If nobody persuades me otherwise, I'm going to make lt_dlmalloc, lt_dlrealloc
and lt_dlfree undocumented backwards compatibility stubs that are not used
by libltdl.  I think removing this mess from libltdl will improve its
maintainability immensely.

Cheers,
        Gary.
- --
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAaqJFFRMICSmD1gYRAg03AKC8Td1RuulZ/2iUrqpCnCu2UI0RKgCfTpTm
tb3Lx90wJ6HsRnJ+oE6T/58=
=+4I4
-----END PGP SIGNATURE-----