From: "wenyi,xie" <xiewenyi2@huawei.com>
To: Laszlo Ersek <lersek@redhat.com>, <devel@edk2.groups.io>,
<jian.j.wang@intel.com>, <hao.a.wu@intel.com>,
<dandan.bi@intel.com>, <eric.dong@intel.com>
Cc: <songdongkuang@huawei.com>
Subject: Re: [edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg/FileExplorerLib: remove redundant null pointer check
Date: Thu, 26 Nov 2020 09:33:46 +0800 [thread overview]
Message-ID: <998734c2-1db2-df65-e0ff-2124bb546d1b@huawei.com> (raw)
In-Reply-To: <931ef6c1-8a00-1f0a-b521-bf4e75541290@redhat.com>
I see. I will correct commit message soon.
Thanks
Wenyi
On 2020/11/25 23:01, Laszlo Ersek wrote:
> On 11/25/20 02:52, wenyi,xie via groups.io wrote:
>> Since Info is a pointer of struct EFI_FILE_SYSTEM_VOLUME_LABEL,
>> and this struct has only one member VolumeLabel which is char
>> array. So Info and Info->VolumeLabel are point to the same
>> address, and if Info != NULL, Info->VolumeLabel == NULL is
>> always false, it's no necessary to do null pointer check again.
>
> I agree with the code change, and I agree with Liming that this is
> material for *after* the stable tag.
>
> However, I disagree with the wording of the commit message. I tried to
> explain why, on edk2-discuss. Let me try again, here.
>
> It is *irrelevant* that "Info", and "Info->VolumeLabel", evaluate to the
> same pointer values (same addresses). Namely, if "VolumeLabel" were
> *not* the first field in EFI_FILE_SYSTEM_VOLUME_LABEL, then this
> equality would cease to hold, but the code change would *still* be
> correct. Which means that the equality ("same address") is *totally
> irrelevant* -- and so it should not be included in the commit message.
>
> Instead, what matters is that, if "Info" is a *valid* pointer (it points
> to a valid EFI_FILE_SYSTEM_VOLUME_LABEL object), then
> "Info->VolumeLabel" is a valid *array object*. The expression
> "Info->VolumeLabel" has type "array of CHAR16". When evaluating an
> expression with array type, the array is implicitly converted to a
> pointer to the first element in the array. See the spec quote below:
>
> ISO C99,
> - 6.3 Conversions
> - 6.3.2 Other operands
> - 6.3.2.1 Lvalues, arrays, and function designators
> - paragprah 3:
>
> Except when it is the operand of the sizeof operator or the unary &
> operator, or is a string literal used to initialize an array, an
> expression that has type "array of type" is converted to an
> expression with type "pointer to type" that points to the initial
> element of the array object and is not an lvalue. [...]
>
> *That* is why (Info != NULL) guarantees that (Info->VolumeLabel !=
> NULL). Because, we take (Info != NULL) to mean (*Info) is a valid
> EFI_FILE_SYSTEM_VOLUME_LABEL object. And so (Info->VolumeLabel) is an
> array object, Info->VolumeLabel[0] is a valid CHAR16 object, and the
> address of a valid CHAR16 object *cannot be* NULL. For the latter, see
> the following spec excerpt:
>
> ISO C99,
> - 6.3 Conversions
> - 6.3.2 Other operands
> - 6.3.2.3 Pointers
> - paragprah 3:
>
> An integer constant expression with the value 0, or such an
> expression cast to type void*, is called a null pointer constant.
> [55] If a null pointer constant is converted to a pointer type, the
> resulting pointer, called a null pointer, is guaranteed to compare
> unequal to a pointer to any object or function.
>
> Footnote [55]: The macro NULL is defined in <stddef.h> (and other
> headers) as a null pointer constant; see 7.17.
>
>
> Please replace the commit message with the following:
>
> """
> If "Info" is a valid pointer to an EFI_FILE_SYSTEM_VOLUME_LABEL
> structure, then "Info->VolumeLabel" denotes a valid array object. When
> the "Info->VolumeLabel" expression is evaluated, as seen in the
> LibFindFileSystem(), it is implicitly converted to
> (&Info->VolumeLabel[0]). Because the object described by the expression
> (Info->VolumeLabel[0]) is a valid CHAR16 object, its address can never
> compare equal to NULL. Therefore, the condition (Info->VolumeLabel ==
> NULL) will always evaluate to FALSE. Substitute the constant FALSE into
> the "if" statement, and simplify the resultant code (eliminate the dead
> branch).
> """
>
> Thanks
> Laszlo
>
>>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Dandan Bi <dandan.bi@intel.com>
>> Cc: Eric Dong <eric.dong@intel.com>
>> Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com>
>> ---
>> MdeModulePkg/Library/FileExplorerLib/FileExplorer.c | 10 +++-------
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
>> index 58e49102593c..13a214b06af9 100644
>> --- a/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
>> +++ b/MdeModulePkg/Library/FileExplorerLib/FileExplorer.c
>> @@ -821,13 +821,9 @@ LibFindFileSystem (
>> if (Info == NULL) {
>> VolumeLabel = L"NO FILE SYSTEM INFO";
>> } else {
>> - if (Info->VolumeLabel == NULL) {
>> - VolumeLabel = L"NULL VOLUME LABEL";
>> - } else {
>> - VolumeLabel = Info->VolumeLabel;
>> - if (*VolumeLabel == 0x0000) {
>> - VolumeLabel = L"NO VOLUME LABEL";
>> - }
>> + VolumeLabel = Info->VolumeLabel;
>> + if (*VolumeLabel == 0x0000) {
>> + VolumeLabel = L"NO VOLUME LABEL";
>> }
>> }
>> MenuEntry->DisplayString = AllocateZeroPool (MAX_CHAR);
>>
>
> .
>
prev parent reply other threads:[~2020-11-26 1:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-25 1:52 [PATCH EDK2 v1 0/1] MdeModulePkg/FileExplorerLib: remove redundant null pointer check wenyi,xie
2020-11-25 1:52 ` [PATCH EDK2 v1 1/1] " wenyi,xie
2020-11-25 3:26 ` 回复: [edk2-devel] " gaoliming
2020-11-25 15:01 ` Laszlo Ersek
2020-11-26 1:33 ` wenyi,xie [this message]
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=998734c2-1db2-df65-e0ff-2124bb546d1b@huawei.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