The file contains violations of Rule 7.3 which states as following: The
lowercase character `l' shall not be used in a literal suffix.

This file defines a non-compliant constant used in a macro expanded in a
non-excluded file, so this deviation is needed in order to avoid
a spurious violation involving both files.

No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 447c1e6661..90413c5458 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -139,6 +139,12 @@ particular use of it done in xen_mk_ulong."
 -config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"}
 -doc_end
 
+-doc_begin="Violations in files that maintainers have asked to not modify in the
+context of R7.3."
+-file_tag+={adopted_r7_3,"^xen/common/unlzo\\.c$"}
+-config=MC3R1.R7.3,reports+={deliberate,"any_area(any_loc(file(adopted_r7_3)))"}
+-doc_end
+
 -doc_begin="Allow pointers of non-character type as long as the pointee is
 const-qualified."
 -config=MC3R1.R7.4,same_pointee=false
-- 
2.34.1

On 18.06.2024 11:54, Alessandro Zucchelli wrote:
> The file contains violations of Rule 7.3 which states as following: The
> lowercase character `l' shall not be used in a literal suffix.
> 
> This file defines a non-compliant constant used in a macro expanded in a
> non-excluded file, so this deviation is needed in order to avoid
> a spurious violation involving both files.

Imo it would be nice to be specific in such cases: Which constant? And
which macro expanded in which file?

Jan

On Tue, 18 Jun 2024, Jan Beulich wrote:
> On 18.06.2024 11:54, Alessandro Zucchelli wrote:
> > The file contains violations of Rule 7.3 which states as following: The
> > lowercase character `l' shall not be used in a literal suffix.
> > 
> > This file defines a non-compliant constant used in a macro expanded in a
> > non-excluded file, so this deviation is needed in order to avoid
> > a spurious violation involving both files.
> 
> Imo it would be nice to be specific in such cases: Which constant? And
> which macro expanded in which file?

Hi Alessandro,
if you give me the details, I could add it to the commit message on commit

On 2024-06-20 03:17, Stefano Stabellini wrote:
> On Tue, 18 Jun 2024, Jan Beulich wrote:
>> On 18.06.2024 11:54, Alessandro Zucchelli wrote:
>> > The file contains violations of Rule 7.3 which states as following: The
>> > lowercase character `l' shall not be used in a literal suffix.
>> >
>> > This file defines a non-compliant constant used in a macro expanded in a
>> > non-excluded file, so this deviation is needed in order to avoid
>> > a spurious violation involving both files.
>> 
>> Imo it would be nice to be specific in such cases: Which constant? And
>> which macro expanded in which file?
> 
> Hi Alessandro,
> if you give me the details, I could add it to the commit message on 
> commit

Hi,

The file common/unlzo.c defines the non-compliant constant 
LZO_BLOCK_SIZE as
"256*1024l" (note the 'l'). This file is excluded from ECLAIR analysis 
but
as the constant is used in macro xmalloc_bytes, expanded in non-excluded 
file
include/xen/xmalloc.h, thus these specific violations need this 
configuration
in order to be excluded.

-- 
Alessandro Zucchelli, B.Sc.

Software Engineer, BUGSENG (https://bugseng.com)

On 20.06.2024 15:19, Alessandro Zucchelli wrote:
> On 2024-06-20 03:17, Stefano Stabellini wrote:
>> On Tue, 18 Jun 2024, Jan Beulich wrote:
>>> On 18.06.2024 11:54, Alessandro Zucchelli wrote:
>>>> The file contains violations of Rule 7.3 which states as following: The
>>>> lowercase character `l' shall not be used in a literal suffix.
>>>>
>>>> This file defines a non-compliant constant used in a macro expanded in a
>>>> non-excluded file, so this deviation is needed in order to avoid
>>>> a spurious violation involving both files.
>>>
>>> Imo it would be nice to be specific in such cases: Which constant? And
>>> which macro expanded in which file?
>>
>> Hi Alessandro,
>> if you give me the details, I could add it to the commit message on 
>> commit
> 
> The file common/unlzo.c defines the non-compliant constant 
> LZO_BLOCK_SIZE as
> "256*1024l" (note the 'l'). This file is excluded from ECLAIR analysis 
> but
> as the constant is used in macro xmalloc_bytes, expanded in non-excluded 
> file
> include/xen/xmalloc.h, thus these specific violations need this 
> configuration
> in order to be excluded.

Would it perhaps be easier to swap the l for an L?

Jan

On Thu, 20 Jun 2024, Jan Beulich wrote:
> On 20.06.2024 15:19, Alessandro Zucchelli wrote:
> > On 2024-06-20 03:17, Stefano Stabellini wrote:
> >> On Tue, 18 Jun 2024, Jan Beulich wrote:
> >>> On 18.06.2024 11:54, Alessandro Zucchelli wrote:
> >>>> The file contains violations of Rule 7.3 which states as following: The
> >>>> lowercase character `l' shall not be used in a literal suffix.
> >>>>
> >>>> This file defines a non-compliant constant used in a macro expanded in a
> >>>> non-excluded file, so this deviation is needed in order to avoid
> >>>> a spurious violation involving both files.
> >>>
> >>> Imo it would be nice to be specific in such cases: Which constant? And
> >>> which macro expanded in which file?
> >>
> >> Hi Alessandro,
> >> if you give me the details, I could add it to the commit message on 
> >> commit
> > 
> > The file common/unlzo.c defines the non-compliant constant 
> > LZO_BLOCK_SIZE as
> > "256*1024l" (note the 'l'). This file is excluded from ECLAIR analysis 
> > but
> > as the constant is used in macro xmalloc_bytes, expanded in non-excluded 
> > file
> > include/xen/xmalloc.h, thus these specific violations need this 
> > configuration
> > in order to be excluded.
> 
> Would it perhaps be easier to swap the l for an L?

+1