From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 08F3C388B00E; Mon, 27 Apr 2020 16:07:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08F3C388B00E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1588003676; bh=Mzv4upKfFc1TcMTjpJ/7gMj+bMvAasOJuJKoyjcVY0U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NESuxgYp1bGdlRZVAA0rWVw2WyZJp+sBaN/eInA1OSz4K/5dSe7fS7Rp3zSjlfTvA MG6E/SXSDCMezzac/ze2/jUH3MBP/6YYSVDNRE+MM3YyzV1sMUG64J5C4hR9mwmglr KSRGhixcMhCNpcmAWTu7A6P2VBRzqxoprk/Os238= From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/94769] Possible use of uninitialized variable num Date: Mon, 27 Apr 2020 16:07:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 16:07:56 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94769 --- Comment #4 from Steve Kargl -= -- On Mon, Apr 27, 2020 at 06:27:25AM +0000, stefansf at linux dot ibm.com wro= te: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94769 >=20 > --- Comment #3 from Stefan Schulze Frielinghaus --- > Since one call chain is gfc_resolve_dt -> check_io_constraints -> > compare_to_allowed_values and at least one parameter of > compare_to_allowed_values, from which the initialization of variable num > depends, is passed through non-static function gfc_resolve_dt, the warning > seems valid to me. Although compare_to_allowed_values is supposed to > initialize num, it may return with a non-zero value although num is > not initialized. >=20 compare_to_allowed_values() appears 25 times in io.c; once as a prototype, once as the function, and 23 invocations. This is the function prototype: compare_to_allowed_values (const char *specifier, const char *allowed[], const char *allowed_f2003[], const char *allowed_gnu[], gfc_char_t *value, const char *statement, bool warn, locus *where, int *num =3D NULL); Of those 23 invocations, it is called once with a non-NULL &num argument. That occurence is the one in question. Here is the code: if (!compare_to_allowed_values ("ASYNCHRONOUS", asynchronous, NULL, NULL, dt->asynchronous->value.character.string, io_kind_name (k), warn, &dt->asynchronous->where, &num)) return false; compare_to_allowed_values() returns either 0 or 1. If it is 0, then the if-statement will cause check_io_constraint() to return false and num is never used. If it returns 1, then one needs to worry about num. Prior to the invocation, it is noted that one has static const char *asynchronous[] =3D { "YES", "NO", NULL }; dt->asynchronous->value.character.string is the string parsed from the Fortran program, e.g., OPEN(UNIT=3D10,FILE=3D'foo', ASYNCHRONOUS=3D'str= ing') The initial code in compare_to_allowed_values() is len =3D gfc_wide_strlen (value); if (len > 0) { for (len--; len > 0; len--) if (value[len] !=3D ' ') break; len++; } The above accounts for leading whitespace in value (aka dt->asynchronous->value.character.string), and for a valid value of ASYNCHRONOUS, len =3D 2 or 3. The next chunk of code sets num for a valid value. Here allowed[] =3D asynchronous[]. for (i =3D 0; allowed[i]; i++) if (len =3D=3D strlen (allowed[i]) && gfc_wide_strncasecmp (value, allowed[i], strlen (allowed[i])) = =3D=3D 0) { if (num) *num =3D i; return 1; } If len does not equal 2 or 3, the block of code in the if statement is not execute, num is not set, and the remainder of compare_to_allowed_values= () is executed, generating an error message, and returning 0. A return of 0 means that num is not used in check_io_constraint as it returns false. If len is equal to 2 or 3, then value is compared to "YES" and "NO". If the comparison is true, then num (being a non-NULL pointer) has it target set to either 0 or 1 (i.e., the index of "YES" or "NO" in allowed[]). If the comparison is false, then the block of code in the if statement is not execute, num is not set, and the remainder of compare_to_allowed_values() is executed, generating an error message, and returning 0. A return of 0 means that num is not used in check_io_constraint as it returns false. In other words, a false positive. There are now three choices. 1) Remove the command line option that causes the false positive. 2) Fix gcc to not generate a false positive. 3) Set num to anything you want to silence a false positive. The above are the three options I offered in comment #1.=