[LLVMbugs] [Bug 22769] New: False Positive: Clang analyzer marks variable which is returned as part of a struct as "Value stored to variable is never read"

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Mar 3 03:02:58 PST 2015


http://llvm.org/bugs/show_bug.cgi?id=22769

            Bug ID: 22769
           Summary: False Positive: Clang analyzer marks variable which is
                    returned as part of a struct as "Value stored to
                    variable is never read"
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: simon.brandner at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

In the function from the dlmalloc source code:

size_t dlmalloc_set_footprint_limit(size_t bytes) {
   size_t result; /* invert sense of 0 */
   if (bytes == 0)
    result = granularity_align(1); /* Use minimal size */
    //Clang complains: Value stored to 'result' is never read
    if (bytes == MAX_SIZE_T)
    result = 0; /* disable */
    else
    result = granularity_align(bytes);
    gm->footprint_limit = result;
        //it is returned here:
    return gm->footprint_limit;
        //the original code returns directly without previous assignment, like:
        //return gm->footprint_limit = result;
    }

scan-build complains about "Value stored to 'result' is never read".
As it is returned as part of a struct, I wonder why it needs to be read before.
Does clang expect some sanity check for it?

You can find the entire source at:

https://android.googlesource.com/platform/bionic/+/master/libc/upstream-dlmalloc/malloc.c

-- 
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/20150303/48b19dca/attachment.html>


More information about the llvm-bugs mailing list