From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7733E3844079; Wed, 5 Aug 2020 14:48:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7733E3844079 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1596638896; bh=EafK0Uy1pDGKO1R+7gNdE/NPhVkiyGLUQk2g5JGy3po=; h=From:To:Subject:Date:In-Reply-To:References:From; b=do2kbGBF7+yINGnmj73hRIGWygZmVDTkLJDiKz6yc5OMeGWuGSFN4NnFo7NC+U4sN Ei+rtufhjjsCvA50gHA4RubaD7GFqMyxM7ojucFr+1PV7JlVqNgWZjEL52pe6/R+J8 S2LrbgQJqeMwJcKLOwZUm6DJevIH6smkxWDLRU3s= From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/96468] Warn when an empty while loop could have been a do-while Date: Wed, 05 Aug 2020 14:48:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 10.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: NEW 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: cc 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, 05 Aug 2020 14:48:16 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96468 Martin Sebor changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- It's not clear whether the request is just for the specific case for while loops with a volatile control variable or independent of the qualifier. I think issuing a warning in either case would be worthwhile but for different reasons, and with different messages making a distinction between the kinds= of the potential problems. (The mention of the suggestion to use "while(condition){}" instead makes me think it might be the former.) Thanks to the volatile access in the example in comment #0, the loop will terminate once signaled is set but the intent may have been that it iterate over the body of the preceding block. signaled can be set either in one of= the calls in the block in some signal handler, or even in another thread (in addition to being set prior to the block of course). But in the absence of the volatile (and atomic) qualifier, unless the initi= al value of signaled is non-zero the loop will never terminate regardless of a= ny extraneous accesses to it outside it because all but the first access to it= in the loop is eliminated: int signaled; void f (void) { while (!signaled); }=