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

["Chen, Shuaidong" <Shuaidong.Chen@xxxxxxx>]

On 10/28/2026 3:42 PM, 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.
I came across this while working through MISRA violations on our safety
tree.  As the code is not something the safety work introduced, I sent
the fix here rather than keeping it downstream.

I have now found that upstream already dealt with these two macros, in
e6b68789d42c ("xen/mm: Remove INVALID_{MFN,GFN}_INITIALIZER").  So you
are right that there is no violation upstream - our tree simply predates
that commit and still has INVALID_{MFN,GFN}_INITIALIZER.  What we need
is to backport it, not this patch.

Please drop this one.  Sorry for the noise.
> Further, "That is valid C" contradicts ...
>
> > --- 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
On your other points, briefly: you are right that "That is valid C"
contradicted the comment I added - C11 6.7.9p11 permits the braces, so
"must not" was wrong; and "for cases where _$FOO() cannot be used" does
read better.  The stale Citrix address for Roger was a hand-maintained

CC list on my side; I will use scripts/get_maintainer.pl in future.

Thanks for the review.

--
Thx and BRs,
Shuaidong Chen