NULL check before calling free

Question

Many calls to the C convener code:

if (p) free(p); 

But why? I thought the C standard says that the free function does nothing with a NULL pointer. So why another clear check?

Answer 1

Design:

 free(NULL); 

It was always OK in C, back to the original UNIX compiler written by Dennis Ritchie. Pre-standardization, some poor compilers may not have specified it correctly, but these days any compiler that cannot legitimately call itself a C compiler. Using it usually leads to a clearer, more convenient code.

Answer 2

As I understand it, no-op in NULL was not always there.

In the bad old days, C (back 1986, by the pre-ANSI cc compiler standard) will free (NULL) reset the kernel. Therefore, most developers tested NULL / 0 before calling for free.

The world has come a long way, and it’s that we don’t need to do the test anymore. But old habits die hard;)

http://discuss.joelonsoftware.com/default.asp?design.4.194233.15

Answer 3

I often write " if (p) free(p) ", even if I know that it is not necessary.

I partially blame myself because I found out that in the old days when free(NULL) would be segfault, and I still feel uncomfortable without doing it.

But I also blame the C standard for not being consistent. Would fclose (NULL), for example, be well defined, I would not have problems in writing:

 free(p); fclose(f); 

This is what happens very often when cleaning things. Unfortunately, it seems strange to me to write

 free(p); if (f) fclose(f); 

and I end up being

 if (p) free(p); if (f) fclose(f); 

I know this is not a reasonable reason, but my case :)

Answer 4

Compilers, even if the attachments are not smart enough to know that the function will return immediately. Pressing parameters, etc. On the stack and setting the call up is obviously more expensive than testing the pointer. I find it always good practice to avoid doing anything, even if it doesn't work. Testing a null value is good practice. An even better practice is to make sure your code does not reach this state and therefore completely eliminates the need for testing.

Answer 5

If you rely on this free (0), it is OKAY, and it is normal for your pointer to zero at this point, say so in the comment // may be NULL

It could just be self-evident code saying that I know, I also use p as a flag.

Answer 6

there may be a custom implementation of free () in a mobile environment. In this case, free (0) can cause a problem. (yes, poor implementation)

Answer 7

There are two different reasons why a pointer variable can be NULL:

• because the variable is used for what is called an option type in type theory, and contains either a pointer to an object or NULL to not represent anything,

• because it points to an array and therefore can be NULL if the array is of zero length (since malloc(0) allowed to return NULL defined by the implementation).

Although this is only a logical difference (in C there are no option types or special pointers to arrays, and we just use pointers for everything), it should always be clear how the variable is used.

So that the C standard does not require free(NULL) do nothing, it is necessary that the fact that a successful call to malloc(0) can return NULL . This is not meant as a general convenience, therefore, for the fclose() example, an argument other than NULL is required. Violating permission to call free(NULL) by passing NULL, which does not represent a zero-length array, seems hacky and wrong.