From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mx.groups.io with SMTP id smtpd.web09.526.1624494296588882683 for ; Wed, 23 Jun 2021 17:24:56 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Zc4Ii0XU; spf=pass (domain: gmail.com, ip: 209.85.216.44, mailfrom: kuqin12@gmail.com) Received: by mail-pj1-f44.google.com with SMTP id bb10-20020a17090b008ab029016eef083425so4787808pjb.5 for ; Wed, 23 Jun 2021 17:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NjoyAqwnbXOquFOZytkJYT9Ai+rNiQIYzzEnhky5TiM=; b=Zc4Ii0XUF2UwcOMmySEj+WA4rgUPRkbjE61qzB62O1LEuqgr14qTcwq+X4yn2euW3E k5zbn+qEMY4uxRYb2hfRcc4YN+jMFHKiEbimlnkfVe02qls+PoiELJvMgEzKFVzZ477V lXlKSuetkY3kVuBcY3fVAjymTx9MGvfZf7uKUetr0wuxi+aXZidfCVBR852YxDpMqxvR PrVMDFuPqGXRZ/baZlkqQTwPzkeYkAFAIjw+C0Cgw+tvot0ez8IPrv8cGDIj0OFW979M dhSr4X3tezkEeTmZfi6098DAlHkkV0BeL/A0HhVMYqKzO6aMGsN5xpnmkcURkwtzr2iH Bmnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NjoyAqwnbXOquFOZytkJYT9Ai+rNiQIYzzEnhky5TiM=; b=tsamN76GVm9SOp622fsetgvtQr6T86NA9/N2gN57dx0jCOWjDiK9iJau2y4vv/3qFw jwXnEg+/DTJ91q0MCYXZkwV16PIT8TB7cQYQACR59wnJhu6yPjv8uUAGMygKyr4536Xk WR87AomM8vCuzBQ4Xsi8Avs3jPraUH5kLAz4zku4zF1XfQu78cwb+ucndHRNFF3aPzF4 hlX2p6SBK+e6OSmRD1e+rlr0RZgXRvZbpeZqUSulV3yB4FJIXfnnOHAL0JZXqOsRVFyc Wylk+eGL34Aqq58nVMK5dYgPVka9axKFnd7cLMABD+7C/6zuO1DwAwrUsymj02OdPnz6 lUgQ== X-Gm-Message-State: AOAM531XZa066/WxRd1JF2jD5gy28CbPeJ2S14Q4c/4+r1IzrRPCskW0 AbyhYtEe/jpXvNd7K2pjP8A= X-Google-Smtp-Source: ABdhPJyQ6C3j2C1h9rvL3cyWg10Q2Yt8Nhriwgh4JUeHuTjU4YrkrRNByT+ylW5+JSqa5OMOve7cPg== X-Received: by 2002:a17:902:45:b029:121:8c5b:67a5 with SMTP id 63-20020a1709020045b02901218c5b67a5mr2055350pla.29.1624494296066; Wed, 23 Jun 2021 17:24:56 -0700 (PDT) Return-Path: Received: from [192.168.50.18] ([50.35.88.161]) by smtp.gmail.com with ESMTPSA id v129sm848027pfc.71.2021.06.23.17.24.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Jun 2021 17:24:55 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER To: Laszlo Ersek , =?UTF-8?Q?Marvin_H=c3=a4user?= , devel@edk2.groups.io Cc: Jian J Wang , Hao A Wu , Eric Dong , Ray Ni , Michael D Kinney , Liming Gao , Zhiguang Liu , Andrew Fish , Leif Lindholm , Bret Barkelew , michael.kubacki@microsoft.com References: <20210610014259.1151-1-kuqin12@gmail.com> <93fd191e-e62f-f02e-11d0-403173fcdf42@posteo.de> <817ab349-b7a2-528b-9b78-aa72cefcd25a@posteo.de> <40bffd17-28a6-d280-02b1-628f1b2daa09@posteo.de> From: "Kun Qin" Message-ID: <1525bdb4-abfa-d89a-d7d9-7f8745640bff@gmail.com> Date: Wed, 23 Jun 2021 17:24:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Hi Marvin, I would prefer not to rely on undefined behaviors from different compilers. Instead of using flexible arrays, is it better to remove the `Data` field, pack the structure and follow "VARIABLE_LOCK_ON_VAR_STATE_POLICY" pattern? In that case, OFFSET_OF will be forced to change to sizeof, and read/write to `Data` will follow the range indicated by MessageLength. But yes, that will enforce developers to update their platform level implementations accordingly. Regards, Kun On 06/23/2021 08:26, Laszlo Ersek wrote: > On 06/23/21 08:54, Marvin Häuser wrote: >> On 22.06.21 17:34, Laszlo Ersek wrote: >>> On 06/18/21 11:37, Marvin Häuser wrote: >>>> On 16.06.21 22:58, Kun Qin wrote: >>>>> On 06/16/2021 00:02, Marvin Häuser wrote: >>>>>> 2) Is it feasible yet with the current set of supported compilers to >>>>>> support flexible arrays? >>>>> My impression is that flexible arrays are already supported (as seen >>>>> in UnitTestFrameworkPkg/PrivateInclude/UnitTestFrameworkTypes.h). >>>>> Please correct me if I am wrong. >>>>> >>>>> Would you mind letting me know why this is applicable here? We are >>>>> trying to seek ideas on how to catch developer mistakes caused by this >>>>> change. So any input is appreciated. >>>> Huh, interesting. Last time I tried I was told about incompatibilities >>>> with MSVC, but I know some have been dropped since then (2005 and 2008 >>>> if I recall correctly?), so that'd be great to allow globally. >>> I too am surprised to see >>> "UnitTestFrameworkPkg/PrivateInclude/UnitTestFrameworkTypes.h". The >>> flexible array member is a C99 feature, and I didn't even know that we >>> disallowed it for the sake of particular VS toolchains -- I thought we >>> had a more general reason than just "not supported by VS versions X >>> and Y". >>> >>> The behavior of OFFSET_OF() would be interesting -- the OFFSET_OF() >>> macro definition for non-gcc / non-clang: >>> >>> #define OFFSET_OF(TYPE, Field) ((UINTN) &(((TYPE *)0)->Field)) >>> >>> borders on undefined behavior as far as I can tell, so its behavior is >>> totally up to the compiler. It works thus far okay on Visual Studio, but >>> I couldn't say if it extended correctly to flexible array members. >> >> Yes, it's UB by the standard, but this is actually how MS implements >> them (or used to anyway?). I don't see why it'd cause issues with >> flexible arrays, as only the start of the array is relevant (which is >> constant for all instances of the structure no matter the amount of >> elements actually stored). Any specific concern? If so, they could be >> addressed by appropriate STATIC_ASSERTs. > > No specific concern; my point was that two aspects of the same "class" > of undefined behavior didn't need to be consistent with each other. > > Thanks > Laszlo >