From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.9259.1624461985167560865 for ; Wed, 23 Jun 2021 08:26:25 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YPfJMQh8; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624461984; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9ovTwk/QFebPmmnd0jYdkTygsputeS4sOzIwMrQzHEg=; b=YPfJMQh8LL5H5os0goiFcsTiBe6iJXqGvZqkd9TiBKTiFavRgOWLVWj5wU+BAoRn/TELZO LLy2GmVJtERgrVkkceZf3Ick4FZHooLBb74eNc8/usNVhPvXYl0wpThxaqMgpYP09QjkfZ s26N94KVXXNdkW8YeXce9xKh4oxpamg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-574-8hCYO7CsPSuW--sWuuzE_w-1; Wed, 23 Jun 2021 11:26:22 -0400 X-MC-Unique: 8hCYO7CsPSuW--sWuuzE_w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E1A8DDF8A5; Wed, 23 Jun 2021 15:26:20 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-200.ams2.redhat.com [10.36.112.200]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D33B7604CC; Wed, 23 Jun 2021 15:26:17 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1 0/5] EDK2 Code First: PI Specification: Update EFI_MM_COMMUNICATE_HEADER To: =?UTF-8?Q?Marvin_H=c3=a4user?= , devel@edk2.groups.io, kuqin12@gmail.com Cc: Jian J Wang , Hao A Wu , Eric Dong , Ray Ni , Michael D Kinney , Liming Gao , Zhiguang Liu , Andrew Fish , Leif Lindholm 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: "Laszlo Ersek" Message-ID: Date: Wed, 23 Jun 2021 17:26:16 +0200 MIME-Version: 1.0 In-Reply-To: <40bffd17-28a6-d280-02b1-628f1b2daa09@posteo.de> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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