From: Laszlo Ersek <lersek@redhat.com>
To: "Tomas Pilar (tpilar)" <tpilar@solarflare.com>, edk2-devel@lists.01.org
Subject: Re: [PATCH] MdeModulePkg:disable wraning to pass gcc4.8 build
Date: Mon, 1 Oct 2018 19:48:39 +0200 [thread overview]
Message-ID: <e4131806-14d5-b11b-5b68-2c552fcadf0c@redhat.com> (raw)
In-Reply-To: <7b490137-3c8a-b5e3-9b48-c4ba1a3d588b@solarflare.com>
On 10/01/18 11:23, Tomas Pilar (tpilar) wrote:
> Wouldn't it be better to fix the warnings in code rather than
> silencing them?
The same idea occurred to me, but it really depends on upstream
Oniguruma. The upstream project's issue tracker on github seems quite
active:
https://github.com/kkos/oniguruma/issues
so we could reasonably file a bug report there (and/or submit a pull
request).
However, this (edk2) commit message seems to suggest that the warnings
are only present with gcc-4.8 (and no later gcc releases). This in turn
suggests that the warnings are spurious (presumably, later gcc releases
recognize that none of the affected variables are actually read without
a prior initialization or assignment.)
Hence, upstream Oniguruma might argue that we should fix our compiler --
they might consider gcc-4.8 too old to care -- rather than litter their
code with superfluous assignments, just to pacify gcc-4.8.
(Obviously, if any one of those warnings is valid, then we *must* fix it
in upstream Oniguruma first, and backport the fix.)
... For reference, I've now built RegularExpressionDxe as follows (using
gcc-4.8.5-28.el7_5.1.x86_64):
build -t GCC48 -b DEBUG -a X64 \
-p MdeModulePkg/MdeModulePkg.dsc \
-m MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
and I get the following 3 "maybe-uninitialized" warnings (currently:
errors):
(1)
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c: In
> function 'compile_length_tree':
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regcomp.c:1516:7:
> warning: 'len' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> int len;
> ^
I think this is an invalid warning; the type of the controlling
expression (node->type) is enum GimmickType, and the case labels cover
all values of the enum. An assert(0) could be added, I guess, but again,
upstream Oniguruma would be justified to reject the idea.
(2)
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
> function 'parse_callout_args.isra.10.constprop.30':
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6753:25:
> warning: 'rl' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> vals[n].l = rl;
> ^
This warning is invalid, given:
6749 if (cn > 0) {
6750 long rl;
6751 r = parse_long(enc, buf, bufend, 1, LONG_MAX, &rl);
6752 if (r == ONIG_NORMAL) {
6753 vals[n].l = rl;
Because parse_long() only returns ONIG_NORMAL after it sets (*rl).
(3)
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c: In
> function 'parse_callout_of_name.constprop.29':
> MdeModulePkg/Universal/RegularExpressionDxe/Oniguruma/regparse.c:6861:38:
> warning: 'tag_end' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
^
This warning is also invalid, given:
6852 if (c == '[') {
6853 if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
6854 tag_start = p;
6855 while (! PEND) {
6856 if (PEND) return ONIGERR_END_PATTERN_IN_GROUP;
6857 tag_end = p;
6858 PFETCH_S(c);
6859 if (c == ']') break;
6860 }
6861 if (! is_allowed_callout_tag_name(enc, tag_start, tag_end))
6862 return ONIGERR_INVALID_CALLOUT_TAG_NAME;
6863
To see that, first we should note:
#define PEND (p < end ? 0 : 1)
therefore PEND doesn't change if neither "p" nor "end" change.
Second, when we reach line 6855 (the "while") for the very first time,
(!PEND) is certainly true (i.e., PEND is false), because otherwise we
would have bailed at line 6853. Therefore we reach line 6857, and assign
"tag_end". Regardless of whether we iterate zero or more *additional*
times around the loop, "tag_end" will have been set, whenever we reach
line 6861.
So, I think I agree with this patch, but the commit message should be a
*lot* more detailed. (Basically, include the analysis from above.)
Thanks
Laszlo
> On 29/09/18 02:55, Dongao Guo wrote:
>> Change-Id: I782962e4994a8edf14beb7ede8b1aabe233dc3a8
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> ---
>> MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> index 16e91bd..07bc02e 100644
>> --- a/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> +++ b/MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
>> @@ -109,3 +109,6 @@
>>
>> # Oniguruma: error: variable 'fp' set but not used
>> GCC:*_*_*_CC_FLAGS = -Wno-error=unused-but-set-variable
>> +
>> + # Oniguruma: tag_end in parse_callout_of_name
>> + GCC:*_*_*_CC_FLAGS = -Wno-error=maybe-uninitialized
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
next prev parent reply other threads:[~2018-10-01 17:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-29 1:55 [PATCH] MdeModulePkg:disable wraning to pass gcc4.8 build Dongao Guo
2018-09-29 2:20 ` Gao, Liming
2018-09-29 2:29 ` Zeng, Star
2018-10-01 9:23 ` Tomas Pilar (tpilar)
2018-10-01 17:48 ` Laszlo Ersek [this message]
2018-10-01 18:01 ` Laszlo Ersek
2018-10-08 3:04 ` Gao, Liming
2018-10-08 10:49 ` Laszlo Ersek
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=e4131806-14d5-b11b-5b68-2c552fcadf0c@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