[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH][for-4.19 v2 1/1] xen: introduce a deviation for Rule 11.9
- To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 17 Oct 2023 08:51:27 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Ry6UbNeoxsnonY9lAwDQb65Wy4a9o21j6VWdkv7ewyA=; b=E2vmo78k+NkjS4oY0FThVQ/j9CI560lKkuzvsmmVnhB1SfjakgNSh4Tq5XspDwhxI/P1XPaMK2P/p+LaQZfHfV6CnwqAI97qb87VOC/gMrLS47MFNOCzOoUY/hm+tQGAAtI1EldQFIArD/94fuwVImjNvA+zLQ8+HuBZoPajYKf9T6KtTXTab81KYyr31Jr8cOJebbhxAZEBKhNRSIYQaDTSMYg0OSznUOpN62NJ6ep512WbMtJ7Cx4VWwIRfwUjGqPgAKmZWJsqTsEF1VEA7UGOnOqbLu1XKNjf1760jopa+10VLxmtFrHz3pSKyvlfYVKd3r+Rxir6oedKSe3mew==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cESuwN5Yw4ZlFZdaED9+EvMNn2JAYK8A4mnhC8yrKYYQ+PJoOu2spupe02I7jcPuLHZ1adHyXsRMPpdw7KA6KxjcchxPfuPY9pWxPlxyHDUvKTFpP5pe46ECvHevKFOJIPeItShoJ5K9oAE2K3ozy/8fs+zO9joYgMto0Ptgio8dBbOyzqJ8B3iso3Wg83MIQPS57pVdFYaCsCsiU5Vi9OSgJJyOs4cFZCitS5UpgG7pGUTMvgm0SAp5v1ETHQhL0y1WbP0DKUnK6kdN1xAKGWquOuljk3wS5eI/L7i0QBw1R06NalXxDhffDJy9bFCATJsRLq26wPR/DqecdPZDAw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, roger.pau@xxxxxxxxxx, Simone Ballarin <simone.ballarin@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 17 Oct 2023 06:51:40 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 16.10.2023 18:49, Nicola Vetrini wrote:
> On 16/10/2023 15:43, Jan Beulich wrote:
>> On 11.10.2023 14:46, Nicola Vetrini wrote:
>>> --- a/xen/include/xen/compiler.h
>>> +++ b/xen/include/xen/compiler.h
>>> @@ -109,13 +109,16 @@
>>>
>>> #define offsetof(a,b) __builtin_offsetof(a,b)
>>>
>>> +/* Access the field of structure type, without defining a local
>>> variable */
>>> +#define access_field(type, member) (((type *)NULL)->member)
>>
>> This is not a field access, so I consider the macro misnamed. Question
>> is
>> whether such a helper macro is needed in the first place.
>>
>>> +#define typeof_field(type, member) typeof(access_field(type, member))
>>
>> If this needs adding, it wants to come ...
>>
>>> /**
>>> * sizeof_field(TYPE, MEMBER)
>>> *
>>> * @TYPE: The structure containing the field of interest
>>> * @MEMBER: The field to return the size of
>>> */
>>> -#define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)->MEMBER))
>>> +#define sizeof_field(TYPE, MEMBER) sizeof(access_field(TYPE, MEMBER))
>>
>> ... with a commend similar as this one has. (Or the commend could be
>> slightly altered to cover both).
>>
>
> I added access_field since it's possibly useful on its own in the
> future,
> but that may not be the case. Not a real field access, perhaps a
> fake_access_field?
I don't like this either, I'm afraid: This isn't a fake access. Maybe
field_of() or field_of_type()? Yet at this point I'd still prefer for
this to not be a separate macro in the first place.
Jan
|