Thread: Is my C++ compiler broken?

I keep getting this warning (mingw32):

warning: passing NULL used for non-pointer converting 2 of `void* memset(void*, int, size_t)'

generated from this line of code:

Code:

memset( array, NULL, sizeof(array) );

Now if NULL expands to 0 or 0L as supposed in C++, and the second arg to memset is an integer (in any sane world), what the heck is my compiler complaining about not being able to be convert NULL to int?!
Furthermore I get the same problem when using "(int)NULL" to explicit cast, yet it is fine with all of "(long)NULL", "(char) NULL" and "(int)(char)NULL" and "(int)(void*)NULL...!!

It's not an error; your code will work.

But NULL is supposed to represent a null pointer. That's what any person expects when they see the keyword NULL. So the compiler is warning you that a passing a null pointer to the second argument of memset does not work as a typical user of the keyword NULL would expect.

Basically it's enforcing a very very common stylistic policy by means of this warning. Seriously, don't use NULL for anything but pointers. It will confuse anyone trying to read your code. Use 0. I'd even suggest not using NULL at all, but since your compiler is able to give this warning, the argument against it doesn't really apply until you change compilers.

It probably has NULL defined like this:

Code:

#define NULL  (void*)0

You can verify it by looking in the compiler's header files.

No, because then it wouldn't be able to mention NULL in the warning. It seems to be treating NULL as a special symbol, like the proposed nullptr. But as long as the above code works, I don't think that qualifies as a standards violation. EDIT: as long as only the warning mechanism is aware of the difference; NULL has to still be treated like a macro, as far as being redefined and the like.

I had cstdlib included (which should pull in the NULL define), but including cstddef results in the same warning.
Here is how it's defined in cstddef:

Code:

#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL		/* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else   /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else   /* C++ */
#define NULL 0
#endif  /* C++ */
#endif  /* G++ */

It must be using something other than the (void *), because that would result in a conversion error.
Searching google with the warning brings up some problems in gcc flagging improper warnings, so I was wondering if this could have been it.

The array is an array of pointers, I initialize with NULL to complement that concept (I know initialization is by byte and pointers are usually multi-byte, but it achieves what I want plus servers as a handy reminder). Regardless, using an explicit cast should avoid this warning.... or put another way, the compiler treats (int)NULL as a warning but accepts (long)NULL, odd...

> memset( array, NULL, sizeof(array) );
Second param is an int, so just do
memset( array, 0, sizeof(array) );

Why are you worrying about how your particular compiler declares NULL?

I'm not, but I am worried that, regardless of its definition, it should be standards-compliant. So an explicit conversion to int flagging a warning, much less a warning where (long)NULL isn't, definitely gets me worried (especially from one of the better-known compilers).

If you're ever intending to set an array of pointers to NULL, then it might interest you to know that although assigning zero to a pointer will in fact set the pointer to a null value, a null pointer doesn't necessarily have to be represented by all bits being zero. Thus using a memset to all bits being zero isn't 100% portable.

Also, should NULL be defined as some other value than 0, your code may well fail, as memset, although its second argument is an integer, will set the memory to the BYTE (or char) value of the second argument, not the integer value - so let's say for arguments sake that NULL is defined as 0x12345678 - you would be setting the memory to 0x78, 0x78, 0x78 - so your array would contain 0x78787878, and a comparison "if (array[i] == NULL)" would not work.

--
Mats

Just call the compiler by its name, GCC. It won't hurt anybody.

Next, the C++ standard merely says:

The macro NULL is an implementation-defined C++ null-pointer constant in this International Standard

It doesn't matter what NULL is defined as, as long as the compiler documents it somewhere and it is a valid null pointer constant. GCC defines it to be __nullptr, which (for backwards compatibility) can be converted to the integer 0, but will emit a warning if this is done.

Originally Posted by grumpy

Yes, indeed. NULL is not required to have a zero value. However, assigning some_pointer = 0 is required to have the same effect as setting that pointer to NULL, and comparing that pointer with NULL is required to yield a true (non-zero in C) result.

Originally Posted by CornedBee

It doesn't matter what NULL is defined as, as long as the compiler documents it somewhere and it is a valid null pointer constant. GCC defines it to be __nullptr, which (for backwards compatibility) can be converted to the integer 0, but will emit a warning if this is done.

A note at the end of the sentence that CornedBee quoted states: "Possible definitions include 0 and 0L, but not (void*)0."

Furthermore, section 4.10 of the 2003 edition of the C++ Standard states: "A null pointer constant is an integral constant expression rvalue of integer type that evaluates to zero."

So, if NULL is an implementation defined null pointer constant, and a null pointer constant evaluates to zero, then it seems to me that NULL is required to have a zero value, even if it is not actually the literal 0.

Interesting. This means that GCC would be non-compliant if it didn't allow conversion from __nullptr to int. On the other hand, nothing is preventing it from emitting a warning if __nullptr is used in integer context.

Of course, we should remember Norman Diamond:

Just because the standard provides a cliff in front of you, you are not necessarily required to jump off it.