From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.10851.1624376074749218385 for ; Tue, 22 Jun 2021 08:34:34 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IydswfZR; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624376073; 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=nPBKSR6GZZSl2WRsBCIaXmXBlDsT2R2QkradUFamjBU=; b=IydswfZRIPOm/xRfTLBDxKTqj/Mm9zAgHEGvksZsiwe6HvdSwH/t+8j6V+KfagNnvV6A3t ScQ6fYO1Czd0jKhgmCmcFlseYDlI9MVejdfhQ57Wc2RAsph+rIhdkqeNu14uy5yEWhmmQC 3rYQFbgjT1n+Ml6eOp4jUTtZlrfhrQY= 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-487-hivEwa2QO4qe1LbRn1bz5w-1; Tue, 22 Jun 2021 11:34:25 -0400 X-MC-Unique: hivEwa2QO4qe1LbRn1bz5w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DD8471084F5E; Tue, 22 Jun 2021 15:34:22 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-52.ams2.redhat.com [10.36.115.52]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B9371009962; Tue, 22 Jun 2021 15:34:20 +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> From: "Laszlo Ersek" Message-ID: Date: Tue, 22 Jun 2021 17:34:18 +0200 MIME-Version: 1.0 In-Reply-To: <817ab349-b7a2-528b-9b78-aa72cefcd25a@posteo.de> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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/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. Thanks Laszlo > I feel > like if the structure is modified anyway, it should probably get a > trailing flexible array over the 1-sized hack. What do you think?