[llvm-bugs] [Bug 46993] New: Warn when an empty while loop could have been a do-while

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Aug 4 10:46:38 PDT 2020


https://bugs.llvm.org/show_bug.cgi?id=46993

            Bug ID: 46993
           Summary: Warn when an empty while loop could have been a
                    do-while
           Product: clang
           Version: 10.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: josephcsible at gmail.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    neeilans at live.com, richard-llvm at metafoo.co.uk

Consider this C code:

typedef int sig_atomic_t;
volatile sig_atomic_t signaled;
_Bool getX(int *);
void processX(int);
void f(void)
{
    {
        int x;
        if(getX(&x))
            processX(x);
    }
    while(!signaled);
    /* do some other stuff */
}

There's two possibilities for what the author meant for it to do:
1. Do getX (and maybe processX) once (in a block just to minimize the scope of
x), then busy-wait until signaled becomes true, and then do some other stuff.
This is what it actually does.
2. Keep doing getX (and maybe processX) in a loop until signaled becomes true,
and then do some other stuff. This isn't what it actually does, because the
author forgot the "do" keyword.

We currently emit no relevant warnings for this code, even when compiled with
"-Weverything". I propose that when we see "while(condition);", we warn that a
"do" may be missing, and if it's not, that you should use "while(condition){}"
instead (except in cases where it's impossible to just be missing the "do"
keyword, like if the "while" is at the beginning of a block).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200804/c9a24230/attachment.html>


More information about the llvm-bugs mailing list