libtool-patches
[Top][All Lists]
Advanced

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

Re: show function pointer evaluations


From: Ralf Wildenhues
Subject: Re: show function pointer evaluations
Date: Fri, 1 Oct 2004 12:31:06 +0200
User-agent: Mutt/1.5.6+20040722i

* Daniel Reed wrote on Fri, Oct 01, 2004 at 12:07:32AM CEST:
> On 2004-09-30T22:56+0100, Gary V. Vaughan wrote:
> ) Ralf Wildenhues wrote:
> ) > I know this is not required by ANSI C (and thus not a bug per se), but
> ) > it's IMVHO clearer to see where function pointers are evaluated.
> ) > (and, what's more, it helps me finding these other nasty bugs :)
> ) Okay.  I'm not especially bothered which style we use, as long as we use
> ) one consistently.  Since you are being such a whirlwind in the bug
> ) fixing dept.  I've already applied this to HEAD...
> 
> The syntax:
> 
>       action(target, value);
> 
> will work regardless of whether action is a macro, a function, or a function
> pointer. The syntax:
> 
>       (*action)(target, value);
> 
> will require rewrites if action's label type changes. In the opposite, but
> perhaps more-frequent case, if action changes from a function to a function
> pointer, there becomes a style conflict that will not be shown as a syntax
> error.

Well, the cases I actually changed were all of the type
(struct->memberfunction), so this rewrite does not apply in their case.
But you do have a point there (for the general case).

> I would encourage the patch be reverted and any future style guidelines
> request that function pointers be dereferenced syntactically just like
> functions are called.

I do not have any personal preferences here, so your argument sounds
fine to me.  Maybe I can explain: I ran `splint'[1] over the libltdl
code, which not only requires a fair amount of annotation, but also
mucks over some valid C constructs, as above.  BTW, this is how I found
some of the bugs I reported.

Regards,
Ralf

[1] http://splint.org




reply via email to

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