[Top][All Lists]

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

Re: [RFC] pre-c89 in libltdl

From: Gary V. Vaughan
Subject: Re: [RFC] pre-c89 in libltdl
Date: Wed, 31 Mar 2004 12:28:52 +0100
User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

Hash: SHA1

Howard Chu wrote:
|>Why?  Because we can offload maintenance of a whole bunch of lowlevel
|>compatibility stuff to the gnulib folks eventually if we
|>accept that their
|>list of supported platforms is good enough.  That in turn
|>will make libltdl
|>smaller and cleaner.
| This sounds odd to me. I suppose there's a large number of systems out there
| now that support the SVR4 dlopen() interface, and that's wonderful for them.
| Having recently ported libltdl to IBM z/OS I'm wary of anything that assumes
| that dlopen is universal though. I know it's now supported on recent versions
| of AIX too, but having managed to cause a kernel panic the first time I used
| that (way back on AIX 4.2.1) I've never trusted it, and always build for the
| native AIX shared library mechanism instead.
| I don't understand how being allowed to use ANSI function prototypes means
| that libltdl can get smaller. ??

I didn't explain myself very well there.  My bad.  Nothing to do with dlopen()
as such:

libltdl currently tries to support K&R compilers (though I don't have such
an environment to test on these days), where gnulib requires c89.  If libltdl
is prepared to require c89, it can use gnulibs versions of xmalloc, xstrdup,
strchr, memcpy, memmove etc.  libltdl itself will probably get a bit bigger in
fairness, but the amount of code in ltdl.c maintained by us will be smaller.

If I can throw away the K&R cruft, that will reduce the LOC in ltdl.[ch] even

- --
Gary V. Vaughan      ())_.  address@hidden,}
Research Scientist   ( '/
GNU Hacker           / )=
Technical Author   `(_~)_
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


reply via email to

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