[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: show function pointer evaluations,
Ralf Wildenhues <=