Re: Function-like macro with the same name as a typedef confuses Coccinelle

[Peter Maydell]

On Thu, 2 Apr 2020 at 13:06, Markus Armbruster <address@hidden> wrote:
>
> I discovered that Vladimir's auto-propagated-errp.cocci leaves
> hw/arm/armsse.c unchanged, even though it clearly should change it.
> Running spatch with --debug prints (among lots of other things)

> Clearly, Coccinelle is getting spooked to easily.

Is it worth asking on the coccinelle mailing list about whether
coccinelle could be made to be less picky in this area ?

> Regardless, three questions:
>
> 1. Are ALL_CAPS typedef names a good idea?  We shout macros to tell
> readers "beware, possibly magic".  Shouting other stuff as well
> undermines that.
>
> 2. The compiler is quite cool with us using the same name for a
> function-like macro and a not-function-like non-macro.  But is it a good
> idea?

Probably not a great idea, and if we really only do it 3 times
it's not too hard to change I suppose. I think this basically
arises when the natural name for the struct happens to be all
uppercase already because the device name is an acronym. We
don't usually titlecase acronyms in structure names (eg
we say 'SCSIBus', not 'ScsiBus'), and (legacy exceptions aside)
we don't usually tack on a trailing 'State' or 'Device'
to the main device state struct these days -- so if your device's
natural name is an acronym then the struct ends up all-caps.
If we don't like all-caps struct names then ideally we'd
adjust one or the other of those conventions so we have a
consistent way to avoid them.

For 'ARMSSE' we could I suppose rename it 'ArmSSE', which would
be in line with current corporate branding but out of line with
most of the other places we use 'ARM' in a struct name :-)

Q: how many all-upper-case typedefs do we have in total (whether
they have a clashing macro or not)? Your argument 1 would
suggest we should look to change them all, not merely the ones
Coccinelle trips over.

thanks
-- PMM