[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


  • To: Federico Serafini <federico.serafini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 5 Mar 2024 17:29:53 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: andrew.cooper3@xxxxxxxxxx, george.dunlap@xxxxxxxxxx, julien@xxxxxxx, bertrand.marquis@xxxxxxx, roger.pau@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxx>, roberto.bagnara@xxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Delivery-date: Tue, 05 Mar 2024 16:30:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 04.03.2024 17:36, Jan Beulich wrote:
> 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.

And btw, see https://lists.xen.org/archives/html/xen-devel/2024-03/msg00159.html
for yet another slightly different pattern that I'd rather not see becoming
"forbidden".

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.