«

James Kanze <>, on 08/09/2010 09:38:59, wrote:

> On Sep 8, 12:08 pm, "Francesco S. Carta"<entul...@gmail.com> wrote:
>> James Kanze<james.ka...@gmail.com>, on 08/09/2010 03:49:48, wrote:
>>> On Sep 7, 8:59 pm, Juha Nieminen<nos...@thanks.invalid> wrote:
>>>> Alf P. Steinbach /Usenet<alf.p.steinbach+use...@gmail.com> wrote:
>
>>>>>> That sounds like a potential source of lots of problems.
>
>>>>> Not only potential...
>
>>>>> And most everybody agree, and that's why 'nullptr_t' and
>>>>> 'nullptr' are introduced in C++0x.
>
>>>> But there's a difference between:
>
>>>> someFunction(0)
>
>>>> and:
>
>>>> const int zero = 0;
>>>> someFunction(zero);
>
>>>> The latter is unambiguously an int, not a pointer.
>
>>> No more so than the first. The argument in both cases is
>>> a constant expression having type int, and evaluating to zero.
>
>>> Of course, a compiler *could* do something special,
>>> depending on the spelling. G++ does: if you use NULL in
>>> a context where an integral type is expected, g++ generates
>>> a warning. (But it doesn't warn if you use 0 in a context
>>> where a pointer is expected.)
>
>> That should depend on how you're compiling the source.
>
> There might be an option to turn it off. With no options, I get
> the warning from g++ 4.1.1 (under Linux, the only version I have
> handy at present).
>
>> At least in
>> MinGW, compiling in C++ mode, NULL is perfectly fine assigned to an int,
>> because NULL is defined as 0. Compiling in C mode it's another matter,
>> because NULL is defined as ((void*)0).
>
> Then MinGW have modified g++ or the libraries somehow. Try the
> following program:
>
> #include<stddef.h>
> #include<iostream>
>
> #define S1(s) #s
> #define S(s) S1(s)
>
> int f(int i)
> {
> return i;
> }
>
> int
> main()
> {
> std::cout<< "NULL = \""<< S(NULL)<< "\"\n";
> std::cout<< f(NULL)<< '\n';
> return 0;
> }
>
> Compiling (with simply g++ nullptr.cc) gives me:
> nullptr.cc: In function 'int main()':
> nullptr.cc:22: warning: passing NULL to non-pointer argument 1 of
> 'int f(int)'
>
> And running:
> NULL = "__null"
> 0

Same output but no warning at all here - don't ask me why, I have no
idea :-/

But I must correct myself, of course, because compiling with the default
settings, NULL gets defined as __null, as your test proved, in my setup.

An excerpt from stddef.h on my setup:

#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++ */
#endif /* NULL not defined and <stddef.h> or need NULL. */
#undef __need_NULL

When I looked at that section to confirm my memory I took for granted
that my files were getting compiled in C++ mode, not in __GNUG__ mode,
whatever that means!

> The C and C++ standards are actually fairly close in this
> respect: the macro NULL must be defined as something specifying
> a null pointer constant. And a null pointer constant is an
> integral constant expression evaluating to 0; C also allows the
> null pointer constant to be such an expression explicitly
> converted to void*, but that's an innovation of the
> C standard---in traditional C, and on most platforms I've seen,
> NULL has been #define'd to 0 in C. (Of course, it can be
> #define'd to anything that is a null pointer constant: "(1-1)",
> "'\0'", "0L"... or even something like "__null", provided the
> compiler ensures that __null is treated as a null pointer
> constant.)
>
>> Interestingly, Stroustrup wrote that this is a case where the
>> type checking system in C is stricter than in C++.
>
> I'd be surprised by that. The reason ((void*)0) is not allowed
> as a null pointer constant in C++ is because unlike in C,
> a void* doesn't implicitly to any other pointer type. (It's not
> really a valid reason, since int's require compiler magic to
> work as well; that compiler magic could have been extended to
> ((void*)0) as well.)

An excerpt from page 7 of:
http://www2.research.att.com/~bs/sibling_rivalry.pdf

"[...] C89’s definition of v o i d * allows a definition of the null
pointer that can’t be assigned to an i n t . I believe this to be the
only point where C is more strongly typed than C++."

I misrepresented his words (he wrote "more strongly typed" whereas I
recalled "stricter type checking system") but that should make no
difference.

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com