PTHREAD_COND_INITIALIZER vs Splint

I have the following code

static pthread_mutex_t watchdogMutex = PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t watchdogCond = PTHREAD_COND_INITIALIZER;

and I get the following errors/warnings when using Splint

Static watchdogCond._data._mutex initialized to null 开发者_开发知识库 value: watchdogCond._data._mutex = (void )0 A reference with no null annotation is assigned or initialized to NULL. Use /@null@*/ to declare the reference as a possibly null pointer. (Use -nullassign to inhibit warning)

What is the issue with this and is it a real danger?

---

It sounds like splint has an issue with explicit initialization of pointers as null., and wants some kind of override-annotation comment to disable the warning. I would simply follow its advice and use the -nullassign option to disable this warning. There is nothing bad or harmful about what your code is doing or the way the implementation has defined the initializer macros. It's just splint having irrational fears.

---

It seems that pthread_mutex_t is an opaque pointer (you could track the typedef down to find out). In Splint, pointers are not-nullable by default. If you want to have a nullable pointer, you must declare it with the semantic annotation /*@null@*/, for example:

char * ptr1;
/*@null@*/ char * ptr2;

ptr1 = NULL; /* warning: implicitly not-nullable pointer */
ptr2 = NULL; /* OK: explicitly nullable pointer */

According to the manual, there are 3 options regarding null state:

• null Possibly null pointer.
• notnull Non-null pointer.
• relnull Relax null checking. No errors when NULL is assigned to it, or when it is used as a non-null pointer.

The advantage of using not-nullable pointers is that you don't need to check them every time you get one of them. For example, you could annotate a function parameter as /*@notnull@*/ and then you are not required to check if(pointer == NULL) before you dereference it. This reduces checking and simplifies your code.

The danger of ignoring these warnings is that, if you are telling Splint that a specific pointer can't possibly be null and later on you try to assign NULL to it, this null pointer could end up being derefered and the program could crash.

In my opinion, your actual issue is Splint's policy, which considers all pointers implicitly not-nullable. This forces you to annotate all your possibly null pointers.