|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 2/3] docs/misra/rules.rst: add rule 5.5
On 04.03.2024 16:39, Federico Serafini wrote: > On 04/03/24 15:17, Jan Beulich wrote: >> On 04.03.2024 14:31, Federico Serafini wrote: >>> On 01/03/24 09:06, Jan Beulich wrote: >>>> On 01.03.2024 00:28, Stefano Stabellini wrote: >>>>> On Wed, 14 Feb 2024, Federico Serafini wrote: >>>>>> On 14/02/24 14:15, Jan Beulich wrote: >>>>>>> On 14.02.2024 12:27, Federico Serafini wrote: >>>>>>>> On 14/02/24 09:28, Jan Beulich wrote: >>>>>>>>> On 13.02.2024 23:33, Stefano Stabellini wrote: >>>>>>>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx> >>>>>>>>>> --- >>>>>>>>>> docs/misra/rules.rst | 6 ++++++ >>>>>>>>>> 1 file changed, 6 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>>>>>>>>> index c185366966..931158b354 100644 >>>>>>>>>> --- a/docs/misra/rules.rst >>>>>>>>>> +++ b/docs/misra/rules.rst >>>>>>>>>> @@ -181,6 +181,12 @@ maintainers if you want to suggest a change. >>>>>>>>>> headers (xen/include/public/) are allowed to retain >>>>>>>>>> longer >>>>>>>>>> identifiers for backward compatibility. >>>>>>>>>> + * - `Rule 5.5 >>>>>>>>>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_05.c>`_ >>>>>>>>>> + - Required >>>>>>>>>> + - Identifiers shall be distinct from macro names >>>>>>>>>> + - Clashes between function-like macros and non-callable >>>>>>>>>> entities >>>>>>>>>> + are allowed. The pattern #define x x is also allowed. >>>>>>>>> >>>>>>>>> Just for me to know what exactly is covered (hence also a question >>>>>>>>> to Roberto as to [to be] implemented Eclair behavior): Even when >>>>>>>>> the above would be sufficient (and imo better) people frequently >>>>>>>>> write >>>>>>>>> >>>>>>>>> #define a(x, y) b(x, y) >>>>>>>>> >>>>>>>>> which, transformed to the specific case here, would then be >>>>>>>>> >>>>>>>>> #define a(x, y) a(x, y) >>>>>>>>> >>>>>>>>> I'd assume such ought to also be covered, but that's not clear >>>>>>>>> from the spelling above. >>>>>>>> >>>>>>>> I list what happens in some different situations, >>>>>>>> then we can find the right words for the documentation and/or >>>>>>>> refine the configuration: >>>>>>>> >>>>>>>> If you >>>>>>>> #define x x >>>>>>>> and then use `x' as identifier, >>>>>>>> the resulting violation is deviated (allowed pattern). >>>>>>>> >>>>>>>> If you >>>>>>>> #define a(x, y) a(x, y) >>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>> entities). >>>>>>>> If you use identifier `a' for a callable entity, the resulting >>>>>>>> violation >>>>>>>> is reported: the allowed pattern covers only macros expanding to their >>>>>>>> own name, in this case the macro name is considered to be >>>>>>>> `a' only, not a(x, y). >>>>>>>> >>>>>>>> If you >>>>>>>> #define a(x, y) b(x, y) >>>>>>>> and then use `a' as identifier for a non-callable entity, >>>>>>>> the resulting violation is deviated (no clash with non-callable >>>>>>>> entities). >>>>>>> >>>>>>> I'm afraid I don't see what violation there is in this case, to >>>>>>> deviate. As a result I'm also not sure I correctly understand the >>>>>>> rest of your reply. >>>>>> >>>>>> #define a(x, y) b(x, y) >>>>>> >>>>>> int a; // Violation of Rule 5.5. >>>>>> >>>>>> The macro name `a' that exist before the preprocessing phase, >>>>>> still exists after the preprocessing phase as identifier for the integer >>>>>> variable and this is a violation. >>>>>> >>>>>>>> If you use `a' as identifier for a callable entity, >>>>>>>> this is not a violation because after the preprocessing phase, >>>>>>>> identifier `a' no longer exists. >>>>>> I correct myself: >>>>>> if you use `a' as identifier for a *function*, >>>>>> it is not a violation because after the preprocessing phase >>>>>> the identifier `a' no longer exists, for example: >>>>>> >>>>>> #define a(x, y) b(x, y) >>>>>> >>>>>> void a(int x, int y); // Ok. >>>>> >>>>> Federico, do you have a better wording suggestion for this rule? >>>>> >>>>> Jan, any further requests here? What would you like to see as next step? >>>> >>>> A more concise wording proposal would probably help. >>> >>> What do you think about: >>> >>> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst >>> index 1e134ccebc..a975b9a85f 100644 >>> --- a/docs/misra/rules.rst >>> +++ b/docs/misra/rules.rst >>> @@ -181,6 +181,13 @@ maintainers if you want to suggest a change. >>> headers (xen/include/public/) are allowed to retain longer >>> identifiers for backward compatibility. >>> >>> + * - `Rule 5.5 >>> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_05_05.c>`_ >>> + - Required >>> + - Identifiers shall be distinct from macro names >>> + - Macros expanding to their own name are allowed (e.g., #define x x). >>> + Clashes between names of function-like macros and identifiers of >>> + non-callable entities are allowed. >> >> Imo that still leaves open e.g. the >> >> #define a(x, y) a(x, y) >> >> case: Permitted ("own name") or not permitted ("a" pretty clearly is expected >> to be a callable entity here, besides being a function-like macro)? > > I would not consider your example as a macro that expands to its own > name, the macro name is considered to be `a' only. That's what I was assuming, and hence my asking back. I think the above ought to be permitted just like "#define x x", and hence the suggested text would need expanding, to ... > Rather, you example can be used to trigger the "callable-noncallable" > part of the deviation, for example: > > #define a(x, y) a(x, y) > > void a(int x, int y); /* Not permitted (callable entity 'a'). */ ... prevent this ("not permitted") from happening. I'm pretty sure you've already found instances of this pattern in our code base. Jan > void foo(int a); /* Permitted (non-callable entity `a'). */ >
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |