[LLVMbugs] [Bug 16558] New: [analyzer] False positive with zero guard in malloc

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sun Jul 7 15:04:27 PDT 2013


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

            Bug ID: 16558
           Summary: [analyzer] False positive with zero guard in malloc
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
          Assignee: kremenek at apple.com
          Reporter: solo-cfe at goeswhere.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Using clang 1:3.4~svn185771-1~exp1 (llvm-toolchain-wheezy), the code (note the
malloc(1) case):

#include <stdint.h>
#include <string.h>
#include <stdlib.h>

void *smalloc(size_t size) {
    if (size == 0) {
        return malloc(1);
    } else {
        return malloc(size);
    }
}

char *dupstr(const char *s) {
    const int len = strlen(s);
    char *p = smalloc(len + 1);
    strcpy(p, s);
    return p;
}


% clang -Weverything --analyze -c that.c
misc.c:16:5: warning: String copy function overflows destination buffer
    strcpy(p, s);
    ^~~~~~~~~~~~
1 warning generated.


Size cannot be zero, and, even if it is, the behaviour is still correct? 
Removing the size == 0 case fixes this.

I can't even fathom what's going on here.  To be clear: I believe this code is
correct and I don't know why an error is coming out.

Sample derived from real code; it wants to always return at least a zero-length
string (i.e. one byte), but the s(afe)malloc reimplementation is used
everywhere, and most analysises hence fail.

--

Debian clang version 3.4-1~exp1 (trunk) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix

Linux om 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux

-- 
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/20130707/95e77869/attachment.html>


More information about the llvm-bugs mailing list