checker-0.223 do not report null pointer using

[llvmbot]

Bugzilla Link	5312
Version	unspecified
OS	MacOS X
Reporter	LLVM Bugzilla Contributor
CC	@tkremenek,@xuzhongxing

Extended Description

checker-0.223 do not report code:

char c = (char)malloc(100); char d = (char)malloc(100); if (c) { c = NULL; } memcpy(c, d, 100); // c is NULL but no report generate.

[d4e15ef9-ffb5-4988-bc6f-d8a3b3e1d54a]

Why is this a bug? clang reports warning on my linux system.

clang will only report a warning if memcpy has been decorated with the nonnull attribute. For example, on Mac OS X this isn't the case:

void memcpy(void , const void *, size_t);

But I was considering extend clang-cc to take an external file in which we can provide some auxiliary information like this or functions that do not return. But I haven't decided the syntax to use. Shall we just provide the function name and its attributes like:

foo noreturn

or use full function signature like:

void foo(char *s) attribute ((noreturn))

Not clear. The former has the benefit of being short and succinct, and parsing is quick.

The latter requires that we can actual parse the line, which begets a whole series of questions. Do we require typedefs to be defined? What about classes?

For now I prefer the first approach, i.e., "foo noreturn". We can create a special naming scheme to handle namespaces, overloading, etc., that is quick to resolve. Since we're mainly focused on C and Objective-C right now, the names are simple, and we can generalize later (for example, we'll need to consider how to handle function overloading for C++). Moreover, if we want to go to approach #​2 in the future, we can always do since a tool can transform #​2 into

​1.

I prefer the first, too. Then we need some ad hoc notations to expression complex attributes, like memcpy @​1 nonnull @​2 nonnull

'@1' stands for 'the first argument', etc.

Another suggestion: should we use tablegen? I'm not certain if the external file should be provided at compile time or runtime. If we opt for compile time, then tablegen is a good fit.

I think both is required. builtin ones can be generated by tablegen. It's also convenient to let the users specify their ones. But we can adapt to tblgen gradually.

[tkremenek]

Why is this a bug? clang reports warning on my linux system.

clang will only report a warning if memcpy has been decorated with the nonnull attribute. For example, on Mac OS X this isn't the case:

void memcpy(void , const void *, size_t);

But I was considering extend clang-cc to take an external file in which we can provide some auxiliary information like this or functions that do not return. But I haven't decided the syntax to use. Shall we just provide the function name and its attributes like:

foo noreturn

or use full function signature like:

void foo(char *s) attribute ((noreturn))

Not clear. The former has the benefit of being short and succinct, and parsing is quick.

The latter requires that we can actual parse the line, which begets a whole series of questions. Do we require typedefs to be defined? What about classes?

For now I prefer the first approach, i.e., "foo noreturn". We can create a special naming scheme to handle namespaces, overloading, etc., that is quick to resolve. Since we're mainly focused on C and Objective-C right now, the names are simple, and we can generalize later (for example, we'll need to consider how to handle function overloading for C++). Moreover, if we want to go to approach #​2 in the future, we can always do since a tool can transform #​2 into #​1.

Another suggestion: should we use tablegen? I'm not certain if the external file should be provided at compile time or runtime. If we opt for compile time, then tablegen is a good fit.

[d4e15ef9-ffb5-4988-bc6f-d8a3b3e1d54a]

Why is this a bug? clang reports warning on my linux system.

But I was considering extend clang-cc to take an external file in which we can provide some auxiliary information like this or functions that do not return. But I haven't decided the syntax to use. Shall we just provide the function name and its attributes like:

foo noreturn

or use full function signature like:

void foo(char *s) attribute ((noreturn))

[tkremenek]

This can possibly be implemented by modifying 'CheckAttrNonNull' to also consult a known list of function:parameter pairs that cannot accept a null pointer.

[llvmbot]

assigned to @tkremenek