Should i use null in c

There are a lot of C habits that are hard to break, and it can be daunting to identify what features are actually useful to learn. I aim to highlight useful features and specific behavioral changes for embedded C developers. The general rule of thumb that I recommend is that you should start using nullptr whenever you would have used NULL in the past.

Traditionally, the NULL macro is an implementation defined constant representing a null pointer, usually the integer 0. Because of this ambiguity, I recommend switching exclusively to nullptr.

To quote cppreference with a code example :. And I also am aware that it is a widely used idiom. To repair this mess, C could easily evolve by adding two things:. Skip to content I always thought that using NULL whenever I wanted to assign a null pointer value to a pointer was a good thing, but today I learned the contrary.

Then later 7. In summary, NULL obfuscates an expression that can be either of integer type or of pointer type. Whenever you want to initialize or assign to a pointer to a null value, use plain 0 , it does serve well. Previous Previous post: A generic swap implementation. Next Next post: P99 is released. Follow Following. Jens Gustedt's Blog Join other followers. I don't like macros, and there's no guarantee that some third party header you're using doesn't redefine NULL to be something odd.

I once worked on a machine where 0 was a valid address and NULL was defined as a special octal value. On that machine 0!

I prefer NULL because it documents your intent. However, that doesn't mean that they are both good programming practices. Help readers of your code understand your thought process.

NULL, 0, 0. They should be used as such. NULL is a pointer, 0 is quantity, 0x0 is a value whose bits are interesting etc. I know some communities encourage demonstrating in-depth knowledge of an environment by breaking the environment's contracts. Responsible programmers, however, make maintainable code and keep such practices out of their code. Strange, nobody, including Stroustroup mentioned that. While talking a lot about standards and aesthetics nobody noticed that it is dangerous to use 0 in NULL 's stead, for instance, in variable argument list on the architecture where sizeof int!

Like Stroustroup, I prefer 0 for aesthetic reasons, but one has to be careful not to use it where its type might be ambiguous. Mostly personal preference, though one could make the argument that NULL makes it quite obvious that the object is a pointer which currently doesn't point to anything, e.

Another facet to the argument is whether you should use logical comparisons implicit cast to bool or explicity check against NULL, but that comes down to readability as well.

I prefer to use NULL as it makes clear that your intent is the value represents a pointer not an arithmetic value. The fact that it's a macro is unfortunate, but since it's so widely ingrained there's little danger unless someone does something really boneheaded. I do wish it were a keyword from the beginning, but what can you do?

That said, I have no problem with using pointers as truth values in themselves. Just as with NULL, it's an ingrained idiom. To work around this error, we would have to cast NULL explicitly:. So, what is it? No big deal! At first sight, colorStr1 and colorStr2 look identical. So, if we compare them, they should be equal, right?

If you run this program, it displays colorStr1! We declare two functions, like that:. Since these functions have the same name, they are overloads, meaning that the compiler calls one or the other depending on the type of the argument.