By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,383 Members | 2,070 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,383 IT Pros & Developers. It's quick & easy.

printf() error with long double and null pointer.

P: n/a
Hello all,

Before stating my question, I should mention that I'm fairly new to C.

Now, I attempted a small demo that prints out the values of C's numeric
types, both uninitialised and after assigning them their maximum defined
values. However, the output of printf() for the long double 'ld' and the
pointer of type void 'v_p', after initialisation don't seem to be right.

The compiler used was gcc (mingw) with '-Wall', '-std=c99' and
'-pedantic' switches. No warnings were emitted. Incidentally the MS
Visual C++ 2003 compiler's output seems okay. I give them both below:

gcc's output:
ld == -1.#QNAN0
or -1.#QNAN
v_p == FFFFFFFF

msvc's output:
ld == 17976931348623157000000000000000000000000000000000 0000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
000000000000000000000000000.000000
or 1.79769e+308
v_p == 00000000

I thought null pointers had a value of zero. Why is gcc's executable
printing ffffffffh? Also the value of 'ld' seems to be wrong.

The code for the demo is:
#include <stdio.h>
#include <limits.h>
#include <float.h>

int main(void) {
char c;
unsigned char uc;
short s;
unsigned short us;
int i;
unsigned int ui;
long l;
unsigned long ul;
float f;
double d;
long double ld;
void *v_p;

printf("c == %c\n\tor %d\nuc == %c\n\tor %u\ns == %hd\nus == %hu\n"
"i == %d\nui == %u\nl == %ld\nul == %lu\nf == %f\n\tor %g\n"
"d == %lf\n\tor %g\nld == %Lf\n\tor %Lg\nv_p == %p\n",
c,c,uc,uc,s,us,i,ui,l,ul,f,f,d,d,ld,ld,v_p);

puts("Initialising them with their maximum allowed values...");
c = CHAR_MAX;
uc = UCHAR_MAX;
s = SHRT_MAX;
us = USHRT_MAX;
i = INT_MAX;
ui = UINT_MAX;
l = LONG_MAX;
ul = ULONG_MAX;
f = FLT_MAX;
d = DBL_MAX;
ld = LDBL_MAX;
puts("Initialising v_p with NULL...");
v_p = NULL;

printf("c == %c\n\tor %d\nuc == %c\n\tor %u\ns == %hd\nus == %hu\n"
"i == %d\nui == %u\nl == %ld\nul == %lu\nf == %f\n\tor %g\n"
"d == %lf\n\tor %g\nld == %Lf\n\tor %Lg\nv_p == %p\n",
c,c,uc,uc,s,us,i,ui,l,ul,f,f,d,d,ld,ld,v_p);
return 0;
}

Where is the mistake?
Thanks for all the help.
Feb 24 '06
Share this Question
Share on Google+
69 Replies


P: n/a
Andrey Tarasevich <an**************@hotmail.com> writes:
fieldfallow wrote:
...
I thought null pointers had a value of zero. Why is gcc's executable
printing ffffffffh? Also the value of 'ld' seems to be wrong.
...


No. A null pointer has value correctly referred to as... well, 'null
pointer value' (NPV). This value can have any physical representation
chosen by implementation: it could be all zeros, it could be 0xFFFFFFFF,
it could be 0xBAADFOOD or anything else. It could also be type-specific,
i.e. different pointer types can use different physical representations
of their NPV.


Right, but as a practical matter, most implementations do happen to
use all-bits-zero as the representation of a null pointer, and the
vast majority of implementations that relatively inexperienced
programmers are likely to run into do so. (If you're using an
implementation that uses a different representation for null pointers,
chances are it's an embedded system and you already know the details
of how it works.)

If you print a null pointer using printf's "%p" format, and the output
looks like a number other than 0, it's *possible* that null pointers
have a representation other than all-bits-zero, but it's more likely
that something else has gone wrong. (And in fact it turned out that
way in this case.)

The first thing I'd try in that case is a minimal program like this:

#include <stdio.h>
int main(void)
{
printf("NULL = %p\n", (void*)NULL);
return 0;
}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 25 '06 #51

P: n/a
Andrey Tarasevich wrote:
fieldfallow wrote:
...
I thought null pointers had a value of zero. Why is gcc's executable
printing ffffffffh? Also the value of 'ld' seems to be wrong.
...


No. A null pointer has value correctly referred to as... well, 'null
pointer value' (NPV). This value can have any physical representation
chosen by implementation: it could be all zeros, it could be 0xFFFFFFFF,
it could be 0xBAADFOOD or anything else. It could also be type-specific,
i.e. different pointer types can use different physical representations
of their NPV.

What is normally meant by "null pointers had a value of zero" is that
constant integral value '0', when used in pointer context, is
automatically interpreted as NPV of the corresponding type (i.e. it is
implicitly replaced with the correct physical representation of the NPV
by the compiler).

For example, if in some implementation value of 0xBAADFOOD is used as
physical representation of NPV or type 'int*' and value 0xFFFFFFFF is
used as physical representation of NPV or type 'double*', the C code

int* pi = 0;
double* pd = 0;

will be translated into a sequence of operations that physically
initialize 'pi' with value 0xBAADFOOD and 'pd' with value of 0xFFFFFFFF.

Thanks Andrey! Your explanation is cleared up my confusion regarding the
issue.
Feb 25 '06 #52

P: n/a
Keith Thompson wrote:
If you print a null pointer using printf's "%p" format, and the output
looks like a number other than 0, it's *possible* that null pointers
have a representation other than all-bits-zero, but it's more likely
that something else has gone wrong. (And in fact it turned out that
way in this case.)

The first thing I'd try in that case is a minimal program like this:

#include <stdio.h>
int main(void)
{
printf("NULL = %p\n", (void*)NULL);
return 0;
}


Here would printf("NULL = %p\n", (void*)0); also be equivalent?

Feb 25 '06 #53

P: n/a
fieldfallow schrieb:
Keith Thompson wrote:
If you print a null pointer using printf's "%p" format, and the output
looks like a number other than 0, it's *possible* that null pointers
have a representation other than all-bits-zero, but it's more likely
that something else has gone wrong. (And in fact it turned out that
way in this case.)

The first thing I'd try in that case is a minimal program like this:

#include <stdio.h>
int main(void)
{
printf("NULL = %p\n", (void*)NULL);
return 0;
}


Here would printf("NULL = %p\n", (void*)0); also be equivalent?


Yes.

-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Feb 25 '06 #54

P: n/a
stathis gotsis wrote:
.... snip ...
I missed that one. What i said applies in this situation:

int *baz = calloc(sizeof *baz);


The only thing that applies in that situation is a diagnostic,
along the lines of "missing parameter".

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Feb 25 '06 #55

P: n/a
"CBFalconer" <cb********@yahoo.com> wrote in message
news:44***************@yahoo.com...
stathis gotsis wrote:

... snip ...

I missed that one. What i said applies in this situation:

int *baz = calloc(sizeof *baz);


The only thing that applies in that situation is a diagnostic,
along the lines of "missing parameter".


Yes you are right, i cut-pasted the previous poster's code. He rather meant:
int *baz = calloc(1,sizeof *baz);
Feb 25 '06 #56

P: n/a
On Fri, 24 Feb 2006 17:39:20 +0530, fieldfallow
<fi*********@gmail.com> wrote in comp.lang.c:
Hello all,

Before stating my question, I should mention that I'm fairly new to C.

Now, I attempted a small demo that prints out the values of C's numeric
types, both uninitialised and after assigning them their maximum defined
values. However, the output of printf() for the long double 'ld' and the
pointer of type void 'v_p', after initialisation don't seem to be right.

The compiler used was gcc (mingw) with '-Wall', '-std=c99' and
'-pedantic' switches. No warnings were emitted. Incidentally the MS
Visual C++ 2003 compiler's output seems okay. I give them both below:

gcc's output:
ld == -1.#QNAN0
or -1.#QNAN
v_p == FFFFFFFF

msvc's output:
ld == 17976931348623157000000000000000000000000000000000 0000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
000000000000000000000000000.000000
or 1.79769e+308
v_p == 00000000

I thought null pointers had a value of zero. Why is gcc's executable
printing ffffffffh? Also the value of 'ld' seems to be wrong.

The code for the demo is:
#include <stdio.h>
#include <limits.h>
#include <float.h>

int main(void) {
char c;
unsigned char uc;
short s;
unsigned short us;
int i;
unsigned int ui;
long l;
unsigned long ul;
float f;
double d;
long double ld;
void *v_p;

printf("c == %c\n\tor %d\nuc == %c\n\tor %u\ns == %hd\nus == %hu\n"
"i == %d\nui == %u\nl == %ld\nul == %lu\nf == %f\n\tor %g\n"
"d == %lf\n\tor %g\nld == %Lf\n\tor %Lg\nv_p == %p\n",
c,c,uc,uc,s,us,i,ui,l,ul,f,f,d,d,ld,ld,v_p);

puts("Initialising them with their maximum allowed values...");
c = CHAR_MAX;
uc = UCHAR_MAX;
s = SHRT_MAX;
us = USHRT_MAX;
i = INT_MAX;
ui = UINT_MAX;
l = LONG_MAX;
ul = ULONG_MAX;
f = FLT_MAX;
d = DBL_MAX;
ld = LDBL_MAX;
puts("Initialising v_p with NULL...");
v_p = NULL;

printf("c == %c\n\tor %d\nuc == %c\n\tor %u\ns == %hd\nus == %hu\n"
"i == %d\nui == %u\nl == %ld\nul == %lu\nf == %f\n\tor %g\n"
"d == %lf\n\tor %g\nld == %Lf\n\tor %Lg\nv_p == %p\n",
c,c,uc,uc,s,us,i,ui,l,ul,f,f,d,d,ld,ld,v_p);
return 0;
}

Where is the mistake?


The mistake is caused by a marketing decision made by Microsoft, and
allowed by the C standard.

Mingw is like a typical gcc implementation for most platforms. That
is, it contains a compiler and headers but no libraries. It uses the
standard libraries that already exist on the host system where it is
installed. On 32-bit Windows, that means Microsoft's C library, so
your printf() call call's Microsoft's printf() functions.

Microsoft made a marketing decision not to support the 80-bit extended
precision type of the Intel FPU, so they implement both double and
long double as the same type, a 64-bit floating point object. See
http://support.microsoft.com/default...b;en-us;129209 for
Microsoft's explanation of this sorry situation.

gcc, on the other hand, uses the Intel 80-bit extended precision type
for long double.

So you are calling a printf() function that expects one floating point
with a "%Lf" conversion specifier, but you are calling it with a
different type of floating point object, and one that is a different
size.

A mis-match like this in a call to printf() causes undefined behavior.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Feb 25 '06 #57

P: n/a
On 2006-02-25, Jack Klein <ja*******@spamcop.net> wrote:
On Fri, 24 Feb 2006 17:39:20 +0530, fieldfallow
<fi*********@gmail.com> wrote in comp.lang.c:
Hello all,

Before stating my question, I should mention that I'm fairly new to C.

Now, I attempted a small demo that prints out the values of C's numeric
types, both uninitialised and after assigning them their maximum defined
values. However, the output of printf() for the long double 'ld' and the
pointer of type void 'v_p', after initialisation don't seem to be right.

The compiler used was gcc (mingw) with '-Wall', '-std=c99' and
'-pedantic' switches. No warnings were emitted. Incidentally the MS
Visual C++ 2003 compiler's output seems okay. I give them both below:

gcc's output:
ld == -1.#QNAN0
or -1.#QNAN
v_p == FFFFFFFF

msvc's output:
ld == 17976931348623157000000000000000000000000000000000 0000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000000000000000000 0000000000000000000000
000000000000000000000000000.000000
or 1.79769e+308
v_p == 00000000

I thought null pointers had a value of zero. Why is gcc's executable
printing ffffffffh? Also the value of 'ld' seems to be wrong.

The code for the demo is:
#include <stdio.h>
#include <limits.h>
#include <float.h>

int main(void) {
char c;
unsigned char uc;
short s;
unsigned short us;
int i;
unsigned int ui;
long l;
unsigned long ul;
float f;
double d;
long double ld;
void *v_p;

printf("c == %c\n\tor %d\nuc == %c\n\tor %u\ns == %hd\nus == %hu\n"
"i == %d\nui == %u\nl == %ld\nul == %lu\nf == %f\n\tor %g\n"
"d == %lf\n\tor %g\nld == %Lf\n\tor %Lg\nv_p == %p\n",
c,c,uc,uc,s,us,i,ui,l,ul,f,f,d,d,ld,ld,v_p);

puts("Initialising them with their maximum allowed values...");
c = CHAR_MAX;
uc = UCHAR_MAX;
s = SHRT_MAX;
us = USHRT_MAX;
i = INT_MAX;
ui = UINT_MAX;
l = LONG_MAX;
ul = ULONG_MAX;
f = FLT_MAX;
d = DBL_MAX;
ld = LDBL_MAX;
puts("Initialising v_p with NULL...");
v_p = NULL;

printf("c == %c\n\tor %d\nuc == %c\n\tor %u\ns == %hd\nus == %hu\n"
"i == %d\nui == %u\nl == %ld\nul == %lu\nf == %f\n\tor %g\n"
"d == %lf\n\tor %g\nld == %Lf\n\tor %Lg\nv_p == %p\n",
c,c,uc,uc,s,us,i,ui,l,ul,f,f,d,d,ld,ld,v_p);
return 0;
}

Where is the mistake?
The mistake is caused by a marketing decision made by Microsoft, and
allowed by the C standard.

Mingw is like a typical gcc implementation for most platforms. That
is, it contains a compiler and headers but no libraries. It uses the
standard libraries that already exist on the host system where it is
installed. On 32-bit Windows, that means Microsoft's C library, so
your printf() call call's Microsoft's printf() functions.

Microsoft made a marketing decision not to support the 80-bit extended
precision type of the Intel FPU, so they implement both double and
long double as the same type, a 64-bit floating point object. See
http://support.microsoft.com/default...b;en-us;129209 for
Microsoft's explanation of this sorry situation.

gcc, on the other hand, uses the Intel 80-bit extended precision type
for long double.


There should be a way to specify the lack of it with an __attribute__,
then.

say, int printf(char *, ...) __attribute__((ldbl64));

Just because one is microsoft and the other is gnu doesn't mean that
mingw isn't "at fault" for not properly supporting the calling
conventions used by the vendor library.
So you are calling a printf() function that expects one floating point
with a "%Lf" conversion specifier, but you are calling it with a
different type of floating point object, and one that is a different
size.

A mis-match like this in a call to printf() causes undefined behavior.


Well, only in that attempting to mix code between different
implementations _always_ causes undefined behavior. The simple fact is
that here is a place that gcc and the microsoft libraries fail to
provide a single coherent implementation.
Feb 25 '06 #58

P: n/a
Jack Klein <ja*******@spamcop.net> writes:
[...]
The mistake is caused by a marketing decision made by Microsoft, and
allowed by the C standard.

Mingw is like a typical gcc implementation for most platforms. That
is, it contains a compiler and headers but no libraries. It uses the
standard libraries that already exist on the host system where it is
installed. On 32-bit Windows, that means Microsoft's C library, so
your printf() call call's Microsoft's printf() functions.

Microsoft made a marketing decision not to support the 80-bit extended
precision type of the Intel FPU, so they implement both double and
long double as the same type, a 64-bit floating point object. See
http://support.microsoft.com/default...b;en-us;129209 for
Microsoft's explanation of this sorry situation.

gcc, on the other hand, uses the Intel 80-bit extended precision type
for long double.

So you are calling a printf() function that expects one floating point
with a "%Lf" conversion specifier, but you are calling it with a
different type of floating point object, and one that is a different
size.

A mis-match like this in a call to printf() causes undefined behavior.


No, a mis-match like this means that the implementation isn't
conforming.

The C standard requires the implementation as a whole to conform to
its requirements, even if different parts of the implementation (the
compiler and the library) are provided by different parties. If the
compiler and library are visibly incompatible, then the implementation
is as non-conforming as if it yielded 3 for (1+1).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Feb 25 '06 #59

P: n/a
fieldfallow wrote:
pete wrote:
fieldfallow wrote:
Hello all,

Before stating my question,
I should mention that I'm fairly new to C.

Now, I attempted a small demo that prints out
the values of C's numeric types, both uninitialised
Accessing uninitialised values like that,
causes undefined behavior in your program.
The undefined behavior can show up in any part
of the program's execution.


Does even printing out the values cause undefined behaviour? Is any
other operation legal, or must I assign them values before I do anything
with them?


Evaluating them without even printing them invokes undefined behaviour. I.e.
int main(void)
{
int a;
a; /* Undefined behaviour */
return 0;
}
Thanks for your answers. The C book I currently have is not very clear
on this point.


I recommend you get a copy of K&R2 and also read the comp.lang.c FAQ at
http://c-faq.com/ (the Bibliography tells you what K&R2 is and
references lots of other good books)
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Feb 25 '06 #60

P: n/a
Jordan Abel wrote:
On 2006-02-24, Richard G. Riley <rg****@gmail.com> wrote:
On 2006-02-24, Jordan Abel <ra*******@gmail.com> wrote:
On 2006-02-24, Richard G. Riley <rg****@gmail.com> wrote:
On 2006-02-24, A. Sinan Unur <1u**@llenroc.ude.invalid> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote in news:468k3hF9qhdjU3
> @individual.net:
>
>> On 2006-02-24, A. Sinan Unur <1u**@llenroc.ude.invalid> wrote:
>>> fieldfallow <fi*********@gmail.com> wrote in news:dtmt1n$1g3$1
>>> @emma.aioe.org:
>>>
>>>> I thought null pointers had a value of zero. Why is gcc's executable
>>>> printing ffffffffh?
>>> http://c-faq.com/null/index.html
>>>
>>> Sinan
>>
>> Which part?
> Start from 5.1, continue until 5.20. The null pointer FAQs are organized
> very well, starting with the definition, and answering each question in a
> way that builds on the previous discussion.
>
> Sinan

Firstly, I'm not trying to be purposefully counter productive
here. But I am confused as to your answer : especially when the OPs
problem was correctly disgnosed elsewhere as nothing to do with the
pointer value.

How would you disagree that the NULL pointer has a value of 0 for the
purposes of comparison and display? Which is what the OP asked and to
suggest he is wrong on this is a misleading thing in the context of
his problems isnt it?

It might not for the purpose of display. Given that the _only_ thing
meaningful you can do with a pointer as far as 'display' is to print it
with the format specifier %p, the "value" of any pointer, including the
null pointer, for the purpose of display is an implementation-defined
string of characters.
Not completely true. You could use an unsigned char pointer to read the
bytes of its representation one at a time and print them.
It was very explicit that NULL and 0 are the same in the context of
pointers and comparisons. Note this is different to internal
representation as covered in other posts in the thread.

But anyhwere else that a NULL pointer is used in terms of being used
for mathematical manipulation of any time its value is 0.
You can't "mathematically manipulate" the null pointer. The only

thing

Sorry. Nomenclature. I (think) meant a pointer which is NULL. Or a
NULLed pointer : is this not a correct term? e.g.

ptr=NULL;


I'd say "null pointer" - "NULL pointer" is not technically correct, but
i knew what you meant. How do you think you can "mathematically
manipulate" it? multiply or divide it by something? take its logarithm
base 10?


Well, you could try addition/subtraction on it, although that invokes
undefined behaviour.
you can do is compare it to another pointer. If you compare it to 0 or
to the macro NULL, that 0 is converted to a pointer before the
comparison.

you mean if I

if(0==ptr)

then 0 is cast to a pointer of same type as ptr? I would expect that.

Hypothetical situation :

a char * which needs to point to memory address 0. What is the
thoughts on this? In this case the pointer must "hold 0" but is not
necessarily a NULL pointer?


Conversion of an integer (i.e. an integer that is not a constant
expression equal to 0) to a pointer is implementation-defined.

If you really needed this, an implementation would probably go about it
by having the internal representation of a null pointer be some other
value, and you'd do (char *)(int)0 [with the cast to int to make the 0
no longer be a null pointer constant].


If you are talking about accessing a HW register or something hard coded
at address 0 then yes, that might be used. Or some other system
dependent memory. If, on the other hand, address 0 is just a normal
address and the compiler happens to put a char array at that address,
you would just access it as you would any other char array.

I.e.,

#include <stdio.h>

int main(void)
{
char fred[] = "my string";
/* compiler places fred at location 0 */
char *derf=0; /* derf does *not* point to fred */
if (derf == fred)
puts("This never happens.");
derf = fred; /* derf now contains address 0 */
return 0;
}

Basically, 0 in the source code is a "magic" symbol. When used in a
pointer context it does *not* mean 0, it means "null pointer constant".
It just happens to be spelt "0".

Another regular here has said he wishes C had a keyword "nil" as the one
and only null pointer constant, and I agree. Where this the case you
could not assign 0 to a pointer or compare a pointer with 0 (except by
using a cast) and the confusion would go away.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Feb 25 '06 #61

P: n/a
In article <5k********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:
gcc, on the other hand, uses the Intel 80-bit extended precision type
for long double.


That seems like a really bad decision on a system whose libraries use
64-bit long doubles. Microsoft's decision may have been unwise, but
it's Mingw's decision that breaks correct programs. As you can see
from this thread, it has the potential to (at the very least) waste
a lot of people's time.

-- Richard
Feb 26 '06 #62

P: n/a
"Richard G. Riley" <rg****@gmail.com> wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
"Richard G. Riley" <rg****@gmail.com> wrote:
Apart from his uninitiliased issues, his comments about null pointers
having a value of zero is fairly common isnt it?


Very common, but also wrong.


Would you agree that a "null pointer" had a value of NULL?


No. NULL is a macro. A null pointer has a null value.

Many of the problems newbies seem to have with null pointers, and
particularly with null pointers in combination with 0, seem to me to
stem from a confusion between a source code and the running executable;
that is, between a null pointer constant and a pointer object which
happens to have a null value. That is why it is IMO important not to
confuse the issue any more by claiming that null pointers have either
zero, or NULL value, or that NULL is zero (while keeping in mind that
NULL _may_ be a (source-level!) 0, but need not be).

Richard
Feb 27 '06 #63

P: n/a
On 2006-02-27, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
"Richard G. Riley" <rg****@gmail.com> wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote:
>
>> Apart from his uninitiliased issues, his comments about null pointers
>> having a value of zero is fairly common isnt it?
>
> Very common, but also wrong.
Would you agree that a "null pointer" had a value of NULL?


No. NULL is a macro. A null pointer has a null value.


I must remember to be more careful

that should read:

" .. had a value of null"
Many of the problems newbies seem to have with null pointers, and
particularly with null pointers in combination with 0, seem to me to
Well, I'm certainly no newbie but would admit to taking some short
cuts in the past with regard to null pointers. Not something I would
be overly proud avout, but something very prevalent in C systems the
world over.
stem from a confusion between a source code and the running executable;
that is, between a null pointer constant and a pointer object which
happens to have a null value. That is why it is IMO important not to
confuse the issue any more by claiming that null pointers have either
zero, or NULL value, or that NULL is zero (while keeping in mind that
NULL _may_ be a (source-level!) 0, but need not be).

Richard


What is a null pointer to you? In standard "conversation" it is for me
a pointer which has a null value or ptr==NULL or (!ptr);
--
Remove evomer to reply
Feb 27 '06 #64

P: n/a
Richard G. Riley wrote:

On 2006-02-27, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
"Richard G. Riley" <rg****@gmail.com> wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote:
> >> having a value of zero is fairly common isnt it?
>
> Very common, but also wrong.
that should read:

" .. had a value of null"


The meaning of "null" is not sufficiently distinct from
the meaning of "zero", in order for the meaning of
"a value of zero" to be different from the meaning of
"a value of null".

--
pete
Feb 27 '06 #65

P: n/a
On 2006-02-27, pete <pf*****@mindspring.com> wrote:
Richard G. Riley wrote:

On 2006-02-27, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote:
>
>> On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
>> > "Richard G. Riley" <rg****@gmail.com> wrote:
>> > >> >> having a value of zero is fairly common isnt it?
>> >
>> > Very common, but also wrong.

that should read:

" .. had a value of null"


The meaning of "null" is not sufficiently distinct from
the meaning of "zero", in order for the meaning of
"a value of zero" to be different from the meaning of
"a value of null".


Yes. I know. We covered all that. But a pointer has a value. Its
something. So NULL is out of the question because it's a macro
..... zero, because it isnt't, and now null because its not
sufficiently distinct? Do I detect a vicious circle here again?

Tell me, what terminology would you use to describe a pointer that has
just had NULL assigned to it?

Or did I misunderstsnd your meaning?

--
Remove evomer to reply
Feb 27 '06 #66

P: n/a

"Richard G. Riley" <rg****@gmail.com> wrote in message
news:46************@individual.net...
On 2006-02-27, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
"Richard G. Riley" <rg****@gmail.com> wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote:
>
>> Apart from his uninitiliased issues, his comments about null pointers >> having a value of zero is fairly common isnt it?
>
> Very common, but also wrong.

Would you agree that a "null pointer" had a value of NULL?


No. NULL is a macro. A null pointer has a null value.


I must remember to be more careful

that should read:

" .. had a value of null"
Many of the problems newbies seem to have with null pointers, and
particularly with null pointers in combination with 0, seem to me to


Well, I'm certainly no newbie but would admit to taking some short
cuts in the past with regard to null pointers. Not something I would
be overly proud avout, but something very prevalent in C systems the
world over.
stem from a confusion between a source code and the running executable;
that is, between a null pointer constant and a pointer object which
happens to have a null value. That is why it is IMO important not to
confuse the issue any more by claiming that null pointers have either
zero, or NULL value, or that NULL is zero (while keeping in mind that
NULL _may_ be a (source-level!) 0, but need not be).

Richard


What is a null pointer to you? In standard "conversation" it is for me
a pointer which has a null value or ptr==NULL or (!ptr);


This is absolute. But null pointer constants are magic. They violate the
normal rules of expression evaluation. In a world with null pointer
constants, we can have
(char *)expr1 != (char *)expr2
even though expr1 == expr2. And if ptr == expr it's not necessarily safe to
say that the value of ptr is the same as the value of expr. You have to
pick your way through the minefield very delicately

--
RSH

Feb 27 '06 #67

P: n/a
Richard G. Riley wrote:

On 2006-02-27, pete <pf*****@mindspring.com> wrote:
Richard G. Riley wrote:

On 2006-02-27, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote:
>
>> On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
>> > "Richard G. Riley" <rg****@gmail.com> wrote:
>> >

>> >> having a value of zero is fairly common isnt it?
>> >
>> > Very common, but also wrong.

that should read:

" .. had a value of null"


The meaning of "null" is not sufficiently distinct from
the meaning of "zero", in order for the meaning of
"a value of zero" to be different from the meaning of
"a value of null".


Yes. I know. We covered all that. But a pointer has a value. Its
something. So NULL is out of the question because it's a macro
.... zero, because it isnt't, and now null because its not
sufficiently distinct? Do I detect a vicious circle here again?

Tell me, what terminology would you use to describe a pointer that has
just had NULL assigned to it?


It's a "null pointer".

--
pete
Feb 27 '06 #68

P: n/a
"Richard G. Riley" <rg****@gmail.com> wrote:
On 2006-02-27, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
"Richard G. Riley" <rg****@gmail.com> wrote:
On 2006-02-24, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
> "Richard G. Riley" <rg****@gmail.com> wrote:
>
>> Apart from his uninitiliased issues, his comments about null pointers
>> having a value of zero is fairly common isnt it?
>
> Very common, but also wrong.

Would you agree that a "null pointer" had a value of NULL?


No. NULL is a macro. A null pointer has a null value.


I must remember to be more careful

that should read:

" .. had a value of null"


In that case, no; I wouldn't complain if someone else called it that,
but I wouldn't phrase it like that myself.
Many of the problems newbies seem to have with null pointers, and
particularly with null pointers in combination with 0, seem to me to


Well, I'm certainly no newbie but would admit to taking some short
cuts in the past with regard to null pointers. Not something I would
be overly proud avout, but something very prevalent in C systems the
world over.


I certainly have done so myself, when I was considerably more of a
newbie than I was now.
stem from a confusion between a source code and the running executable;
that is, between a null pointer constant and a pointer object which
happens to have a null value. That is why it is IMO important not to
confuse the issue any more by claiming that null pointers have either
zero, or NULL value, or that NULL is zero (while keeping in mind that
NULL _may_ be a (source-level!) 0, but need not be).


What is a null pointer to you? In standard "conversation" it is for me
a pointer which has a null value or ptr==NULL or (!ptr);


Yes; but a NULL is something else. A null pointer _compares_ equal to
both NULL and zero - any mathematical zero, including 0.0!), but that's
only because it's an explicit exception, and NULL, where it is literally
a 0, is converted to a null pointer - _not_ the other way 'round.

Richard
Feb 28 '06 #69

P: n/a
On 2006-02-28, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:
Yes; but a NULL is something else. A null pointer _compares_ equal to
both NULL and zero
yes.
- any mathematical zero, including 0.0!)
No. 0.0 is not a null pointer constant.
but that's only because it's an explicit exception, and NULL, where it
is literally a 0, is converted to a null pointer - _not_ the other way
'round.

Richard

Feb 28 '06 #70

69 Replies

This discussion thread is closed

Replies have been disabled for this discussion.