Re: [cocci] Broken code block size determination in function implementations

[Markus Elfring <Markus.Elfring@web.de>]

>> …
>> -> duplicate data
>> file:
>> arch/sh/drivers/pci/common.c
>> function:
>> early_read_config_dword
>> line:
>> 36
>> …
>>
>>
>> https://elixir.bootlin.com/linux/v6.12-rc4/source/arch/sh/drivers/pci/common.c#L33 :
>> …
>> #define EARLY_PCI_OP(rw, size, type)					\
>> int __init early_##rw##_config_##size(struct pci_channel *hose,		\
>> 	int top_bus, int bus, int devfn, int offset, type value)	\
>> {									\
>> 	return pci_##rw##_config_##size(				\
>> 		fake_pci_dev(hose, top_bus, bus, devfn),		\
>> 		offset, value);						\
>> }
…
>> EARLY_PCI_OP(read, dword, u32 *)
>> EARLY_PCI_OP(write, byte, u8)
…
> OK, that was much more understandable.  In general, we don't make a great
> effort to give reasonable results for macro definitions.

Under which circumstances can this situation be adjusted better?


> I don't even know what result is wanted?

The discussed source code search should be restricted to function implementations
(which would usually not be generated by special macros).


> The starting position of each EARLY and th ending position of each )?

Obviously, this description does not fit to the desired data processing goal here.


> I guess the problem is that EARLY_PCI_OP is not recognized as a declarer name,

No information “SPECIAL NAMES: adding … as a declarer” was presented for this test case.


> and so a parse error is found,

I did not see such an indication so far.


> causing the macro to be expanded.
The mentioned test output indicated a questionable function name generation.
How will the software understanding evolve further?

Regards,
Markus