From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5FD923858C74; Wed, 9 Mar 2022 22:32:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5FD923858C74 From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104854] -Wstringop-overread should not warn for strnlen and strndup Date: Wed, 09 Mar 2022 22:32:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.2.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org 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: 11.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc short_desc 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: Wed, 09 Mar 2022 22:32:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104854 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org Summary|[11/12 Regression] |-Wstringop-overread should |-Wstringop-overread should |not warn for strnlen and |not warn for strnlen and |strndup |strndup | --- Comment #3 from Martin Sebor --- The same warning is also issued for some calls to memchr(), strncmp() and probably other built-in functions as well. For example: const char a[] =3D "123"; char* f (int i) { return __builtin_memchr (a + i, '3', 7); } warning: =E2=80=98__builtin_memchr=E2=80=99 specified bound 7 exceeds sou= rce size 4 [-Wstringop-overread] 5 | return __builtin_memchr (a + i, '3', 7); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ y.c:1:12: note: source object allocated here 1 | const char a[] =3D "123"; | ^ In all these cases the warnings are intentional (i.e., it's a feature, and = so not a regression). Their purpose is to point out what could be a coding mistake. With strndup(), since the use case for it rather than strdup() is= to copy an initial substring, specifying a bound that's larger than the length= of the string is pointless. In general, the GCC manual documents warnings as diagnostic messages that report constructions that are not inherently erroneous but that are risky or suggest there may have been an error.=20 So not all instances of any warning should be expected to indicate errors. = In fact, many are known to be benign by design (for example, all instances of -Wchar-subscripts are benign when -funsigned-char is used; many instance of -Waddress are also benign, as are many -Wparentheses, etc.). And although = most middle end warnings tend to be designed to trigger only for invalid stateme= nts (i.e., statements that have undefined behavior if reached during execution), some do also trigger for code that's strictly valid but suspect. Besides t= he -Wstringop-overread examples here, other such warnings include dynamic allocation calls with sizes in excess of PTRDIFF_MAX (-Walloc-size-larger-than), returning the address of a local variable (-Wreturn-local-addr), or in GCC 12, storing the address of a local variabl= e in an extern pointer (-Wdangling-pointer). Deciding what code is suspect enough to warn and under what option (-Wall or -Wextra) is a judgment call; different people have very different ideas.=