From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 66941211A3216 for ; Tue, 8 Jan 2019 09:15:09 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 48FAE394D54; Tue, 8 Jan 2019 17:15:08 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-197.rdu2.redhat.com [10.10.120.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6E2F57D8C4; Tue, 8 Jan 2019 17:15:01 +0000 (UTC) To: "Gao, Liming" , Leif Lindholm Cc: AKASHI Takahiro , Alexander Graf , Heinrich Schuchardt , "trini@konsulko.com" , "robdclark@gmail.com" , "u-boot@lists.denx.de" , "edk2-devel@lists.01.org" , "Wang, Jian J" , "Wu, Hao A" , "Ni, Ray" , "Zeng, Star" , Andrew Fish , "Kinney, Michael D" , Ard Biesheuvel , "Rothman, Michael A" References: <20181214101043.14067-1-takahiro.akashi@linaro.org> <20181214101043.14067-3-takahiro.akashi@linaro.org> <20181217011626.GC14562@linaro.org> <84b6f3fd-ed68-a541-7727-69e5392984e6@suse.de> <20181225083024.GC14405@linaro.org> <20190107140932.uefkly3a3jzlyjjf@bivouac.eciton.net> <7d6fbbff-ca48-588a-6082-bf8b95a7e829@redhat.com> <20190107192220.ugkcxfd3betvuypi@bivouac.eciton.net> <1d1c1e2f-193c-5e1f-f51a-b922b67eb428@redhat.com> <20190108095102.myetfzaancuzq7cx@bivouac.eciton.net> <65b16f57-8d34-87ee-2fcc-8312d333f308@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E3ADCB9@SHSMSX152.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: Date: Tue, 8 Jan 2019 18:15:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3ADCB9@SHSMSX152.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 08 Jan 2019 17:15:08 +0000 (UTC) Subject: Re: [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 17:15:09 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/08/19 16:12, Gao, Liming wrote: > Last, EFI_HII_KEYBOARD_PACKAGE_HDR structure definition doesn't follow UEFI spec. I remember we ever meet with the compiler issue for below style. GCC49 may complaint it. I need to double confirm. > typedef struct { > EFI_HII_PACKAGE_HEADER Header; > UINT16 LayoutCount; > EFI_HII_KEYBOARD_LAYOUT Layout[]; > } EFI_HII_KEYBOARD_PACKAGE_HDR; This is called "flexible array member", and it was introduced in ISO C99. It is not part of the earlier C standards, and I quite expect several of the toolchains currently supported by edk2 to reject it. Code written against earlier releases of the ISO C standard than C99 would use a construct colloquially called the "struct hack", such as typedef struct { EFI_HII_PACKAGE_HEADER Header; UINT16 LayoutCount; EFI_HII_KEYBOARD_LAYOUT Layout[1]; } EFI_HII_KEYBOARD_PACKAGE_HDR; indexing "Layout" with a subscript >= 1. Needless to say, that was always undefined behavior :) C99 introduced the flexible array member precisely for covering the "struct hack" use case with a well-defined construct. There is no portable, pre-C99 way to actually spell out the Layout field in the structure definition, with the intended use case. The most portable approach I can think of would be: - explain the trailing (nameless) array in a comment, - instruct programmers to write manual pointer-to-unsigned-char arithmetic, - once the necessary element is located, copy it into an object actually declared with the element type, and access it there. In edk2 we sometimes do steps #1 and #2, which is OK. But, even in those cases, we almost never do step #3 (because it's both cumbersome and wastes cycles) -- instead, we favor type-punning. Whenever I see that, I tell myself, "we disable the effective type rules with '-fno-strict-aliasing', so this should be fine, in practice. I hope anyway." :) Thanks, Laszlo