[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