On Sun, Mar 05, 2017 at 10:26:53PM +0800, Christopher Li wrote:
> >
> > +static void process_for_loop_decl(struct symbol_list **list, struct symbol *sym)
> > +{
> > + ...
> > + add_symbol(list, sym);
> > + fn_local_symbol(sym);
>
> The more I look at it, the more I feel that the above two lines
> should kind of appear in every process_*_declar function.
I agree and it certainly does for the current two cases.
And it's why I've kept the symbol_list as type.
But I understood you thought differently in your previous
comment:
"The default function can be adding the symbol to a list.
So the struct symbol_list **list should turn into transparent
argument as context for the call back."
> So may be we should just change your patch 4/7 into:
>
> if (!is_typedef) {
>
> + if (process_decl)
> + process_decl(sym);
>
> if (!(decl->ctype.modifiers & (MOD_EXTERN |
> MOD_INLINE))) {
> add_symbol(list, decl);
> fn_local_symbol(decl);
> }
> }
>
> Then for the default case, just pass NULL as process_decl. Might want
> to find a better name for this function callback arguments as well.
>
> Because you are actually not interested in change the behavor of adding
> to the list at all. You just want to get an notification when the symbol does
> get added into the list. Now thing of it, I can't come up with one example
> process_xxx_decl not add the symbol nor doing the fn_local_symbol.
Yes.
I almost came with a solution with an ops struct with two operations:
- one that do some checking
- another that do the 'action' like adding to the list
But then it wasn't needed for the default & c99-for-loop cases here.
I'll see what can be done.
Luc
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
