From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E627321C8D616 for ; Wed, 7 Jun 2017 16:09:11 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B062E40F04; Wed, 7 Jun 2017 23:10:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B062E40F04 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B062E40F04 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-107.phx2.redhat.com [10.3.116.107]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA6477C136; Wed, 7 Jun 2017 23:10:18 +0000 (UTC) From: Laszlo Ersek To: Jordan Justen , edk2-devel-01 Cc: Ard Biesheuvel References: <20170603154203.29907-1-lersek@redhat.com> <20170603154203.29907-2-lersek@redhat.com> <149668486395.8581.9154897144168590783@jljusten-skl> <5e0277a2-0bf4-e8a1-f61f-77cdb896da06@redhat.com> Message-ID: Date: Thu, 8 Jun 2017 01:10:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5e0277a2-0bf4-e8a1-f61f-77cdb896da06@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 07 Jun 2017 23:10:19 +0000 (UTC) Subject: Re: [PATCH 1/1] OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 23:09:12 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/06/17 20:16, Laszlo Ersek wrote: > On 06/05/17 19:47, Jordan Justen wrote: >> On 2017-06-03 08:42:03, Laszlo Ersek wrote: >>> ... by narrower than 8-byte ADD_POINTER references. >>> >>> Introduce the CollectRestrictedAllocations() function, which iterates over >> >> How about Collect32BitRestrictedAllocations and similar treatment for >> other names that just say 'restricted'? > > Something like this crossed my mind, but I didn't know how to prefix the > simple variable / parameter names "RestrictedAllocations" with "32Bit", > as the identifiers cannot start with a digit. > > I even thought of spelling it out, as in > "ThirtyTwoBitRestrictedAllocations", but that seemed ridiculous. > > Prefixing "32Bit" with an underscore, _32Bit, looks ugly, plus the C > standard actually reserves it: > > All identifiers that begin with an underscore are always reserved > for use as identifiers with file scope in both the ordinary and tag > name spaces. > > While I'd only use this variable name as function parameter / local > variable, and thereby I'd shadow any such impl. defined global variable > ("identifiers with file scope"), the shadowing would trigger a compiler > warning for sure, and break the build. > > What do you suggest? Ultimately I went with s/RestrictedAllocations/AllocationsRestrictedTo32Bit/ in the patch body and in the commit message too. Cleaned up the line lengths and such as well, plus retested the patch. Commit 4275f38507a4. Thanks, Laszlo