Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH v2] x86/fpu: use _Alignof to avoid UB in TYPE_ALIGN | Date | Wed, 28 Sep 2022 08:09:01 +0000 |
| |
From: YingChi Long > Sent: 27 September 2022 17:44 > > > Interesting - what justification do they give? > > Linux kernel requires that the compiler add no unnecessary padding > > so that structure definitions are well defined. > > Yes, that's a clarification given in 2019. > > > So using a type definition inside offsetof() won't give a > > useful value - but it still isn't really UB. > > WG14 may worry about commas and the scope of new definitions. So they provide > new words into the standard and said: > > > If the specified type defines a new type or if the specified member is a > > bit-field, the behavior is undefined. > > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
Except that the kernel requires it to be defined.
Did they clarify the clause that required offsetof() to return a compile-time constant? That stops you doing offsetof(struct x, member->array[expression]). (Oh and the compiler for a common OS disallows any version of that even when expression in an integer constant!)
> > I've provided this link in the patch. > > > Has that ever worked? > > Given: > > struct foo { > > int a; > > char b; > > char c; > > }; > > TYPE_ALIGN(struct foo) evaluates to 4 in the previous approach (based on > offsetof). _Align(struct foo) evaluates to the same value. > > See https://godbolt.org/z/sqebhEnsq > > > I think CHECK_MEMBER_AT_END_OF_TYPE(struct foo, b) is true. > > Hmm, both the previous version and after this patch the macro gives me > false. (See the godbolt link).
See https://godbolt.org/z/95shMx44j
It return 1 for a and 0 for b and c (and char d,e following b). NFI what it is trying to do!
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |