From: Laszlo Ersek <lersek@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 1/1] OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
Date: Thu, 8 Jun 2017 01:10:17 +0200 [thread overview]
Message-ID: <e48bd6cc-d38a-ef1d-7e04-b35b7cb3aa35@redhat.com> (raw)
In-Reply-To: <5e0277a2-0bf4-e8a1-f61f-77cdb896da06@redhat.com>
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
next prev parent reply other threads:[~2017-06-07 23:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-03 15:42 [PATCH 0/1] OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted Laszlo Ersek
2017-06-03 15:42 ` [PATCH 1/1] " Laszlo Ersek
2017-06-03 18:33 ` Ard Biesheuvel
2017-06-05 17:47 ` Jordan Justen
2017-06-06 18:16 ` Laszlo Ersek
2017-06-07 23:10 ` Laszlo Ersek [this message]
2017-06-08 10:11 ` Ard Biesheuvel
2017-06-08 18:40 ` Laszlo Ersek
2017-06-08 19:05 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e48bd6cc-d38a-ef1d-7e04-b35b7cb3aa35@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox