On 19.10.2023 18:34, Nicola Vetrini wrote:
> On 19/10/2023 17:57, Jan Beulich wrote:
>> On 19.10.2023 13:04, Nicola Vetrini wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -85,10 +85,10 @@ conform to the directive."
>>> # Series 7.
>>> #
>>>
>>> --doc_begin="Usage of the following constants is safe, since they are
>>> given as-is
>>> -in the inflate algorithm specification and there is therefore no risk
>>> of them
>>> -being interpreted as decimal constants."
>>> --config=MC3R1.R7.1,literals={safe,
>>> "^0(007|37|070|213|236|300|321|330|331|332|333|334|335|337|371)$"}
>>> +-doc_begin="Octal constants used as arguments to macro INSTR_ENC or
>>> MASK_EXTR
>>> +can be used, because they appear as is in specifications, manuals,
>>> and
>>> +algorithm descriptions."
>>> +-config=MC3R1.R7.1,reports+={safe,
>>> "any_area(any_loc(any_exp(macro(^(INSTR_ENC|MASK_EXTR)$))))"}
>>
>> INSTR_ENC() is a local macro in x86'es AMD SVM code. A macro of the
>> same
>> name could imo be introduced without issues in, say, Arm code. The
>> above
>> would then needlessly suppress findings there, aiui.
>>
>> MASK_EXTR() otoh is a global macro which ise used for various purposes.
>> Excluding checking there is imo going too far, too.
>
> I should have thought about it; I can simply enforce the deviation to
> additionally match
> only a specific file for each of the macros.
That'll work for INSTR_ENC(), but not for MASK_EXTR().
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -90,6 +90,12 @@ Deviations related to MISRA C:2012 Rules:
>>> - __emulate_2op and __emulate_2op_nobyte
>>> - read_debugreg and write_debugreg
>>>
>>> + * - R7.1
>>> + - It is safe to use certain octal constants the way they are
>>> defined in
>>> + specifications, manuals, and algorithm descriptions as
>>> arguments to
>>> + macros 'INSTR_ENC' and 'MASK_EXTR'.
>>> + - Tagged as `safe` for ECLAIR.
>>
>> Similarly this wording is imo inappropriate, while ...
>>
>
> I tried to be a bit more specific about what is actually being deviated,
> on the assumption
> that the maintainers and contributors would find it more useful than
> parsing ecl files, but
> if you prefer it to be more general, no problem.
Just dropping everything after the last comma would deal with my concern.
Jan
