[Top][All Lists]

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

Re: ltdl.c and 1.4.1 (type conflicts)

From: Gary V. Vaughan
Subject: Re: ltdl.c and 1.4.1 (type conflicts)
Date: Thu, 13 Sep 2001 20:58:40 +0100
User-agent: Mutt/

On Tue, Sep 11, 2001 at 01:32:33PM -0500, Tim Mooney wrote:
> In regard to: Re: ltdl.c and 1.4.1 (type conflicts), Gary V. Vaughan said...:
> >On Mon, Sep 10, 2001 at 11:29:57AM -0700, Bruce Korb wrote:
> >> "Gary V. Vaughan" wrote:
> >>
> >> > Suggestions?
> >>
> >> 2.  Recast everything as "ptr_t" which is a typedef for "char*".
> >>     Amdhal is the only system I know of with 64 bit proc pointers
> >>     and 32 bit data pointers.  If you gotta support Amdhal, then
> >>     kludge some sort of hack for that weirdo platform.
> >
> >This is what I am doing already.  Isn't it?  (Not the Amdhal bit)
> It looks that way.
> What I think others are suggesting is that a typedef or define for a pointer
> to the exact function prototype be created, and that type is what should
> be used for functions that need to exchange pointers to functions.
> Something similar to what's done on page 147 (section 6.7) of K&R2e --
> create a typedef something like
>       typedef int (*lt_func_ptr)(const char *, lt_ptr);
> and then use `lt_func_ptr' as the type of the argument for functions that
> need to exchange function pointers.  If there are functions with other
> signatures (different return type or different # & type of args), an
> additional typedef would be needed for those as well.

Except that the function argument takes an lt_ptr which it passes
through to a callback function.  Sometimes it is a pointer to a
structure that the callback uses, other times it is a pointer to a
function.  Creating two identical functions, but for whether they pass
through a pointer to a function or a pointer to something else is not
a good idea... I really think that the warning from xlc is

> Of course, most of the functions still use the K&R style arg definitions.
> Maybe it should be switched to using ANSI only, and people should be advised
> to use `ansi2knr' if they need to compile libtool with a pre-ANSI compiler.
> This may not sit well with the gcc people, as we may get into a
> chicken-or-the-egg problem there.  I don't know.

Indeed.  But K&R vs. ANSI is not the reason for this problem.  Anyway,
supporting K&R is really not at all difficult, so I have no problem at
all with doing it.

  ())_. Gary V. Vaughan     gary@(|
  ( '/  Research Scientist       ,_())____
  / )=  GNU Hacker  \'      `&
`(_~)_  Tech' Author   =`---d__/

reply via email to

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