Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Ike Naar

Reply
Thread Tools

Re: Ike Naar

 
 
Keith Thompson
Guest
Posts: n/a
 
      02-08-2009
"Malcolm McLean" <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      02-08-2009
Malcolm McLean wrote:
> "Keith Thompson" <(E-Mail Removed)> wrote in message news:
>> "Malcolm McLean" <(E-Mail Removed)> 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).
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-08-2009
Flash Gordon <(E-Mail Removed)> writes:
> Malcolm McLean wrote:
>> "Keith Thompson" <(E-Mail Removed)> wrote in message news:
>>> "Malcolm McLean" <(E-Mail Removed)> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      02-09-2009
Keith Thompson wrote:
> Flash Gordon <(E-Mail Removed)> writes:
>> Malcolm McLean wrote:
>>> "Keith Thompson" <(E-Mail Removed)> wrote in message news:
>>>> "Malcolm McLean" <(E-Mail Removed)> 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
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      02-20-2009
Golden California Girls <(E-Mail Removed)> wrote:

> Malcolm McLean wrote:
> > "Keith Thompson" <(E-Mail Removed)> 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
 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      02-23-2009
"Malcolm McLean" <(E-Mail Removed)> wrote:

> "Richard Bos" <(E-Mail Removed)> wrote in message news:
> > Golden California Girls <(E-Mail Removed)> wrote:
> >
> >> Malcolm McLean wrote:
> >> > "Keith Thompson" <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Ike Naar Stephen Sprunk C Programming 31 02-15-2009 08:54 PM
Re: Ike Naar Antoninus Twink C Programming 1 02-08-2009 05:26 PM
verandering naar Planet, M VD SAR Computer Support 21 11-29-2005 12:11 AM
(Dutch) Ingrid Schreuder wint een DVD naar keuze voor een budget van 25 euro. Jones DVD Video 0 11-30-2003 04:16 PM
windows millenium naar windows XP Andy Demuyt Computer Support 1 11-19-2003 01:42 PM



Advertisments