Re: [XEN PATCH] xen/typesafe: don't brace-initialize a scalar TYPE_SAFE value

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2026-10-28 08:42, Jan Beulich wrote:
> On 28.10.2026 06:03, Shuaidong Chen wrote:
>> TYPE_SAFE() degrades to a plain typedef in non-debug builds (NDEBUG), 
>> so
>> mfn_t is then `unsigned long' rather than a one-member struct.
>> INVALID_MFN_INITIALIZER and INVALID_GFN_INITIALIZER, however, always
>> expand to `{ ... }', which leaves
>> 
>>     mfn_t first_valid_mfn = { ~0UL };
>> 
>> initializing a scalar from a braced list.  That is valid C, but MISRA
>> C:2012 Rule 9.2 (required) - "The initializer for an aggregate or 
>> union
>> shall be enclosed in braces" - is reported against it, twice in the
>> x86_64 build: common/page_alloc.c and arch/x86/efi/runtime.h.
> Wait - the rule says the opposite; it says nothing about initializers 
> of
> scalars. The rule is clean in all analysis jobs we do. On staging we 
> only
> ever have debug builds analyzed, but on release branches *-allcode have
> DEBUG=n. No 9.2 violation shows up there. You also don't point at 
> Eclair
> output supporting your claim, so I wonder what is going on here.
> 
> Further, "That is valid C" contradicts ...
> 

This was actually an FP present in ECLAIR 3.14.0 (used by Xen), not an 
actual violation:

1|$ /opt/bugseng/eclair-3.14.0/bin/eclair_env 
-enable=MC3A2.R9.2,B.REPORT.TXT -- gcc -c /tmp/fp.c -o /dev/null
violation for rule MC3A2.R9.2: (required) The initializer for an 
aggregate or union shall be enclosed in braces. (untagged)
/tmp/fp.c:1.9-1.11: Loc #1 [culprit: to initialize `int' it was expected 
a scalar but found a compound with 1 element]
int x = {2};
         <~>
nicola@nico:~
0|$ eclair_env -enable=MC3A2.R9.2,B.REPORT.TXT -- gcc -c /tmp/fp.c -o 
/dev/null
nicola@nico:~
0|$ cat /tmp/fp.c
int x = {2};

It has been fixed since ECLAIR 3.15.0. How to proceed (document as FP or 
modify the source to avoid it) is up to the project.

>> --- a/xen/include/xen/typesafe.h
>> +++ b/xen/include/xen/typesafe.h
>> @@ -9,12 +9,17 @@
>>   *  * _$FOO()  which boxes a $TYPE as a $FOO_t
>>   *  * $FOO_x() which unboxes a $FOO_t to $TYPE
>>   *
>> + * TYPE_SAFE_INIT($VAL) spells a constant initializer for a $FOO_t, 
>> for use
>> + * where _$FOO() cannot be (an object of static storage duration).
>> + *
>>   * This makes a $FOO_t and a $BAR_t incompatible even when the box 
>> the same
>>   * $TYPE.
>>   *
>>   * It does have some performance cost because the types now have a 
>> different
>>   * storage attribute, so type safety is only enforced in a debug 
>> build.
>> - * Non-debug builds degrade to a simple typedef and noops for the 
>> functions.
>> + * Non-debug builds degrade to a simple typedef and noops for the 
>> functions,
>> + * and with it TYPE_SAFE_INIT() loses its braces: a scalar must not 
>> be
>> + * brace-initialized.
>>   */
> 
> ... the new wording used here.
> 
> Also, in the earlier insertion above, isn't there "used" missing? 
> Possibly, to
> avoid the double use of "use", with the earlier "use" replaced by 
> "cases"? Yet
> maybe this is legal grammar anyway, and it merely feels odd to me as a 
> non-
> native speaker. A native speaker may want consulting.
> 
> I also wonder why you CC-ed Roger with his old Citrix address.
> 
> Jan

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253