«

"Malcolm McLean" <> writes:
[...]
> Surely there is some rule that NULL can be used as the null pointer
> constnant, in all contexts?

NULL is (or, rather, expands to) a null pointer constant in all
contexts. But a null pointer constant doesn't necessarily result in a
null pointer value in all contexts.

For example:
printf("%p\n", 0);
0 is a null pointer constant, but since it corresponds to the ",..."
in the declaration of printf, the compiler doesn't convert it from int
to any pointer type, and the call passes a value of type int. It
could be passed as the wrong value, the wrong size, or even in the
wrong location. If NULL is defined as 0, which is both legal and
common, then the above is equivalent to:
printf("%p\n", NULL);
To be safe, you need a cast:
printf("%p\n", (void*)NULL);

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Malcolm McLean wrote:
> "Keith Thompson" <kst-> wrote in message news:
>> "Malcolm McLean" <> writes:
>> [...]
>>> Surely there is some rule that NULL can be used as the null pointer
>>> constnant, in all contexts?
>>
>> NULL is (or, rather, expands to) a null pointer constant in all
>> contexts. But a null pointer constant doesn't necessarily result in a
>> null pointer value in all contexts.
>>
>> For example:
>> printf("%p\n", 0);
>> 0 is a null pointer constant, but since it corresponds to the ",..."
>> in the declaration of printf, the compiler doesn't convert it from int
>> to any pointer type, and the call passes a value of type int. It
>> could be passed as the wrong value, the wrong size, or even in the
>> wrong location. If NULL is defined as 0, which is both legal and
>> common, then the above is equivalent to:
>> printf("%p\n", NULL);
>> To be safe, you need a cast:
>> printf("%p\n", (void*)NULL);
>>
> That's another good argument for the campaign for 64 bit ints.

No it isn't. It is a good argument in favour of doing some of the
compile-time checks that gcc (and probably other compiles) does. It is
also a good argument for changing the C standard to require than NULL be
defined as ((void*)0) which is something that all implementations could
easily be changed to do.

> (I suppose it would still break if the null pointer wasn't all bits zero).

Or if the first few pointers are passed in address registers (passing
parameters in registers does happen even with varidac functions).

Flash Gordon <> writes:
> Malcolm McLean wrote:
>> "Keith Thompson" <kst-> wrote in message news:
>>> "Malcolm McLean" <> writes:
>>> [...]
>>>> Surely there is some rule that NULL can be used as the null pointer
>>>> constnant, in all contexts?
>>>
>>> NULL is (or, rather, expands to) a null pointer constant in all
>>> contexts. But a null pointer constant doesn't necessarily result in a
>>> null pointer value in all contexts.
>>>
>>> For example:
>>> printf("%p\n", 0);
>>> 0 is a null pointer constant, but since it corresponds to the ",..."
>>> in the declaration of printf, the compiler doesn't convert it from int
>>> to any pointer type, and the call passes a value of type int. It
>>> could be passed as the wrong value, the wrong size, or even in the
>>> wrong location. If NULL is defined as 0, which is both legal and
>>> common, then the above is equivalent to:
>>> printf("%p\n", NULL);
>>> To be safe, you need a cast:
>>> printf("%p\n", (void*)NULL);
>>>
>> That's another good argument for the campaign for 64 bit ints.
>
> No it isn't. It is a good argument in favour of doing some of the
> compile-time checks that gcc (and probably other compiles) does. It is
> also a good argument for changing the C standard to require than NULL
> be defined as ((void*)0) which is something that all implementations
> could easily be changed to do.

That would help for void* pointers, but not for other pointer types.
I don't think it would matter for anything in the standard library
(assuming char* and void* are interchangeable as arguments), but
consider a variadic function that expects an argument of type int*.
Passing NULL would still pass a null pointer of type void*, which
could be incompatible.

[...]

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
> Flash Gordon <> writes:
>> Malcolm McLean wrote:
>>> "Keith Thompson" <kst-> wrote in message news:
>>>> "Malcolm McLean" <> writes:
>>>> [...]
>>>>> Surely there is some rule that NULL can be used as the null pointer
>>>>> constnant, in all contexts?
>>>> NULL is (or, rather, expands to) a null pointer constant in all
>>>> contexts. But a null pointer constant doesn't necessarily result in a
>>>> null pointer value in all contexts.
>>>>
>>>> For example:
>>>> printf("%p\n", 0);
>>>> 0 is a null pointer constant, but since it corresponds to the ",..."
>>>> in the declaration of printf, the compiler doesn't convert it from int
>>>> to any pointer type, and the call passes a value of type int. It
>>>> could be passed as the wrong value, the wrong size, or even in the
>>>> wrong location. If NULL is defined as 0, which is both legal and
>>>> common, then the above is equivalent to:
>>>> printf("%p\n", NULL);
>>>> To be safe, you need a cast:
>>>> printf("%p\n", (void*)NULL);
>>>>
>>> That's another good argument for the campaign for 64 bit ints.
>> No it isn't. It is a good argument in favour of doing some of the
>> compile-time checks that gcc (and probably other compiles) does. It is
>> also a good argument for changing the C standard to require than NULL
>> be defined as ((void*)0) which is something that all implementations
>> could easily be changed to do.
>
> That would help for void* pointers, but not for other pointer types.
> I don't think it would matter for anything in the standard library
> (assuming char* and void* are interchangeable as arguments), but
> consider a variadic function that expects an argument of type int*.
> Passing NULL would still pass a null pointer of type void*, which
> could be incompatible.

I know it would not help where other pointer types are expected
(technically, although in practice it would for many implementations),
and is possibly dodgy where a char* is expected. However it would be
correct where a void* is expected and, more importantly (in my opinion),
it would guarantee a diagnostic if used where an integer is required.
--
Flash Gordon

Golden California Girls <> wrote:

> Malcolm McLean wrote:
> > "Keith Thompson" <kst-> wrote in message news:

> >> To be safe, you need a cast:
> >> printf("%p\n", (void*)NULL);
> >>
> > That's another good argument for the campaign for 64 bit ints.
>
> Where C&V is it required that pointers be so small as be fit in 64 bits?

Oh, it's worse than that. It's not even required that pointers be the
same size as ints - or that pointers are the same size as other
pointers.

Richard

"Malcolm McLean" <> wrote:

> "Richard Bos" <> wrote in message news:
> > Golden California Girls <> wrote:
> >
> >> Malcolm McLean wrote:
> >> > "Keith Thompson" <kst-> wrote in message news:
> >
> >> >> To be safe, you need a cast:
> >> >> printf("%p\n", (void*)NULL);
> >> >>
> >> > That's another good argument for the campaign for 64 bit ints.
> >>
> >> Where C&V is it required that pointers be so small as be fit in 64 bits?
> >
> > Oh, it's worse than that. It's not even required that pointers be the
> > same size as ints - or that pointers are the same size as other
> > pointers.
> >
> There aren't enough 32 bit integers to go round, even if we ration them
> strictly to one each. However the problem disappears with 64 bit ints.

Large integers are nice, but they have nothing to do with pointers.

> The campaign for 64 bit ints is the campaign for int to be the natural
> integer size on a machine with a 64 bit address space.

That's pretty (though in some circumstances dumb), but all the evidence
I've seen here is that this may be its stated goal, but the one thing it
really campaigns for is for all pointers to be the same as all integers.
Which is truly astoundingly dumb.

> There is a case for fat pointers, but that's a different argument. It isn't
> clear to me that we don't need some tweaks to the standard in order to make
> fat pointers generally useful.

Then you should read the Standard with a more open mind. There is _no_
problem with fat pointers in C, and there can be very good applications
of them, on systems where they make sense.

Richard