[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re:

From: Gary V . Vaughan
Subject: Re: Re:
Date: Thu, 1 Apr 2004 00:32:45 +0100

Hash: SHA1

On 1 Apr 2004, at 00:06, Bob Friesenhahn wrote:
On Wed, 31 Mar 2004, Gary V.Vaughan wrote:
The style of this change confuses me, and it doesn't seem to do
exactly the same thing:

   /* If ARGZ_LEN has shrunk to nothing, release ARGZ's memory.  */
   if (!argz_len)
-    LT_DLFREE (argz);
+    argz = (free (argz), (char *) 0);

Actually, they are exactly the same after cpp is done!

Yes, it guess it is valid C code.

Okay, you got me... that code is gross. It was gross in a macro before, but now it is gross in the body of the code. I guess we need an xfree to hide it.

Gnu programmers are used to the xmalloc api, and it is reimplemented all over the place, and lowers the barrier for contributing, so I'm inclined
to reuse the idiom if possible.  When it comes to splitting out xalloc

GNU programmers are not the only users of libtool and libltdl.

I meant to say that GNU programs that look like each other make it easier
for potential contributers to read them all.

functions, we can leave them static and #include "xalloc.c" into ltdl.c.
Eventually I'd like there to be enough sanity in libltdl source that

It is really poor form to include .c files into .c files.  While it is
true that a number of projects do that (FreeType and libwmf come to
mind), it can cause problems for some tools, particularly automated
Makefile generators or other tools that place significance on files
based on their extension.

Yeah, agreed.

: dons flameproof armour

Now that we don't RTLD_GLOBAL anymore there is no reason for internal apis
to leak into libltdl clients... :-)

someone with a reasonable familiarity with the GNU programming style and
idioms could get to grips with ltdl.c in a few hours... the first step
is eliminating as much macro noise, and not-invented-here-isms as I can.

In some ways the macroized version looks cleaner.

Okay, I went overboard. I think HEAD has too much code between LT_EREALLOC and sbrk. I think my patch 100 has too little. Lets see if 100bis is less
controversial ;-)

- --
Gary V. Vaughan      ())_.  address@hidden,}
Research Scientist   ( '/
GNU Hacker           / )=
Technical Author   `(_~)_

Version: GnuPG v1.2.2 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]