«

Malcolm McLean wrote:
>
> "Han from China" <autistic-> wrote in message news:
>> Ike Navar wrote:
>>> If NULL is defined as plain 0 then an int is passed to the function
>>> where it expects a char*.
>>
>> Anyway, the classic Unix case is the execl() function. If NULL is
>> defined as ((void *) 0), the unadorned NULL works, but if NULL
>> is defined as 0, we have the problem you mention.
>>
> Surely there is some rule that NULL can be used as the null pointer
> constnant, in all contexts?

Nope. NULL is allowed to be defined as 0, in which case it only becomes
a null pointer constant when converted to a pointer; in other contexts,
it's simply an integer. However, this should only matter when used as
an argument to a variadic function; one must cast to an appropriate
pointer type (such as (void*)) in that case. To avoid this common
error, NULL is usually defined as (void*)0 on many implementations --
but that's not required, and for maximum portability one should not
depend on it.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Isaac Jaffe

pete <> writes:

> Stephen Sprunk wrote:
>> Malcolm McLean wrote:
>>>
>>> "Han from China" <autistic-> wrote in message news:
>>>> Ike Navar wrote:
>>>>> If NULL is defined as plain 0 then an int is passed to the function
>>>>> where it expects a char*.
>>>>
>>>> Anyway, the classic Unix case is the execl() function. If NULL is
>>>> defined as ((void *) 0), the unadorned NULL works, but if NULL
>>>> is defined as 0, we have the problem you mention.
>>>>
>>> Surely there is some rule that NULL can be used as the null pointer
>>> constnant, in all contexts?
>>
>> Nope. NULL is allowed to be defined as 0, in which case it only
>> becomes a null pointer constant when converted to a pointer; in
>> other contexts, it's simply an integer.
>
> 0 is a null pointer constant. That's all, no context.
>
> N869
> 6.3.2.3 Pointers
> [#3] An integer constant expression with the value 0, or
> such an expression cast to type void *, is called a null
> pointer constant.

It is also an integer constant or 6.3.2.3 would not apply. It is
clearly both at the same time so why do you seem to be suggesting that
context does not matter?

--
Ben.

Ben Bacarisse <> writes:
> pete <> writes:
>> Stephen Sprunk wrote:
>>> Malcolm McLean wrote:
[...]
>>>> Surely there is some rule that NULL can be used as the null pointer
>>>> constnant, in all contexts?
>>>
>>> Nope. NULL is allowed to be defined as 0, in which case it only
>>> becomes a null pointer constant when converted to a pointer; in
>>> other contexts, it's simply an integer.
>>
>> 0 is a null pointer constant. That's all, no context.
>>
>> N869
>> 6.3.2.3 Pointers
>> [#3] An integer constant expression with the value 0, or
>> such an expression cast to type void *, is called a null
>> pointer constant.
>
> It is also an integer constant or 6.3.2.3 would not apply. It is
> clearly both at the same time so why do you seem to be suggesting that
> context does not matter?

Yes, 0 is both an integer constant and a null pointer constant. I
think pete's point (which I agree with) is that 0 is a null pointer
constant (or at least is "called" a null pointer constant) regardless
of the context in which it appears. The 0 in:
int x = 0;
is by definition a null pointer constant, even though it's not
converted to a pointer type.

--
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 <kst-> writes:

> Ben Bacarisse <> writes:
>> pete <> writes:
>>> Stephen Sprunk wrote:
>>>> Malcolm McLean wrote:
> [...]
>>>>> Surely there is some rule that NULL can be used as the null pointer
>>>>> constnant, in all contexts?
>>>>
>>>> Nope. NULL is allowed to be defined as 0, in which case it only
>>>> becomes a null pointer constant when converted to a pointer; in
>>>> other contexts, it's simply an integer.
>>>
>>> 0 is a null pointer constant. That's all, no context.
>>>
>>> N869
>>> 6.3.2.3 Pointers
>>> [#3] An integer constant expression with the value 0, or
>>> such an expression cast to type void *, is called a null
>>> pointer constant.
>>
>> It is also an integer constant or 6.3.2.3 would not apply. It is
>> clearly both at the same time so why do you seem to be suggesting that
>> context does not matter?
>
> Yes, 0 is both an integer constant and a null pointer constant. I
> think pete's point (which I agree with) is that 0 is a null pointer
> constant (or at least is "called" a null pointer constant) regardless
> of the context in which it appears. The 0 in:
> int x = 0;
> is by definition a null pointer constant, even though it's not
> converted to a pointer type.

Never was I so confused.

I now discover

char *p = 0; /* is the preferred way to create a null pointer +/

And since 0 converts to false in a boolean expression then

if(p){
}

is perfectly valid and the NULL check is completely irrelevant since the
internal representation does not come into it. The 0 value is all that
matters.

Which is brilliant since this is how I treated ptrs for years before
getting quite a nasty shock in c.l.c where I was told I was being
sloppy.

Keith Thompson <kst-> writes:

> Ben Bacarisse <> writes:
>> pete <> writes:
>>> Stephen Sprunk wrote:
>>>> Malcolm McLean wrote:
> [...]
>>>>> Surely there is some rule that NULL can be used as the null pointer
>>>>> constnant, in all contexts?
>>>>
>>>> Nope. NULL is allowed to be defined as 0, in which case it only
>>>> becomes a null pointer constant when converted to a pointer; in
>>>> other contexts, it's simply an integer.
>>>
>>> 0 is a null pointer constant. That's all, no context.
>>>
>>> N869
>>> 6.3.2.3 Pointers
>>> [#3] An integer constant expression with the value 0, or
>>> such an expression cast to type void *, is called a null
>>> pointer constant.
>>
>> It is also an integer constant or 6.3.2.3 would not apply. It is
>> clearly both at the same time so why do you seem to be suggesting that
>> context does not matter?
>
> Yes, 0 is both an integer constant and a null pointer constant. I
> think pete's point (which I agree with) is that 0 is a null pointer
> constant (or at least is "called" a null pointer constant) regardless
> of the context in which it appears.

I thought he was saying a little bit more by "that's all" but I can
see now that that is unlikely.

His correction (that the context only determines whether it becomes a
*null pointer*, not whether it is a null pointer constant) is quite
correct, but I would have stressed that it is always both (since being
both of these things is a very important part of 0) when making the
correction.

--
Ben.

Richard <rgrdev_@gmail.com> writes:

> Keith Thompson <kst-> writes:
>
>> Ben Bacarisse <> writes:
>>> pete <> writes:
>>>> Stephen Sprunk wrote:
>>>>> Malcolm McLean wrote:
>> [...]
>>>>>> Surely there is some rule that NULL can be used as the null pointer
>>>>>> constnant, in all contexts?
>>>>>
>>>>> Nope. NULL is allowed to be defined as 0, in which case it only
>>>>> becomes a null pointer constant when converted to a pointer; in
>>>>> other contexts, it's simply an integer.
>>>>
>>>> 0 is a null pointer constant. That's all, no context.
>>>>
>>>> N869
>>>> 6.3.2.3 Pointers
>>>> [#3] An integer constant expression with the value 0, or
>>>> such an expression cast to type void *, is called a null
>>>> pointer constant.
>>>
>>> It is also an integer constant or 6.3.2.3 would not apply. It is
>>> clearly both at the same time so why do you seem to be suggesting that
>>> context does not matter?
>>
>> Yes, 0 is both an integer constant and a null pointer constant. I
>> think pete's point (which I agree with) is that 0 is a null pointer
>> constant (or at least is "called" a null pointer constant) regardless
>> of the context in which it appears. The 0 in:
>> int x = 0;
>> is by definition a null pointer constant, even though it's not
>> converted to a pointer type.
>
> Never was I so confused.

Yes, there is still some confusion.

> I now discover
>
> char *p = 0; /* is the preferred way to create a null pointer +/

not everyone prefers it, but some do.

> And since 0 converts to false in a boolean expression then
>
> if(p){
> }
>
> is perfectly valid

This is valid but not because of 0 converting to false in a boolean
expression. At least, that phrase has enough vague parts to it that
it is not clear what you mean.

In the "if" you wrote p is not converted. An 'if' is defined in terms
of the expression comparing equal (or not equal) to 0. When a pointer
is compared to 0 it is the 0 that gets converted to a null pointer.
This is why the test is safe and correct even when a null pointer has
a representation that is not all bit zero.

> and the NULL check is completely irrelevant since the
> internal representation does not come into it.

I can't follow this at all. The internal representation is what
determines (sometimes rather obliquely) the value of p so it does come
into it. What matters is whether p compares equal to a null pointer
of the same type.

What do you mean by the NULL check? It is guaranteed that given char *p:

if (p)
if (p == 0)
if (p == NULL)

are all the same.

> The 0 value is all that matters.

It is whether the pointer is or is not a null pointer that matters. I
am not sure if that is what you mean by "the 0 value". 0 is both a
pointer value and an integer value and C can't compare these two
without converting one or the other. Everything is designed to work
if the conversion goes one way:

if (p) => if (p == 0) => 0 converts to a null pointer

but it may not work if you force the conversion the wrong way:

if ((int)p) => if ((int)p == 0) => 0 taken to be an int

what happens here is implementation defined and a null pointer may not
convert to (int)0.

--
Ben.

In article < t>,
Han from China <autistic-> wrote:
....
>If you were managing a large C project, which would you prefer:
>someone who's successfully written complex pieces of software
>that are used by many people throughout the world but who doesn't
>use the ISO-approved terms and definitions when talking C, or
>someone who's written a whole series of small, buggy programs
>but who redeems himself by being able to tell you about trap
>representations and the subtle difference between
>"int main() { ... }" and "int main(void) { ... }"?

You're asking the wrong question. Who cares about what you would do if
you were managing a large C project? Why bring that into the discussion?
That is obviously OT to this group and not something any of the regs
here have done in decades (if ever).

Rather, you should be asking:

If you were teaching a beginner's C class and needed to know how to
prototype main() or whether or not you should cast the return value
of malloc (*), which would you prefer: someone who redeems himself by
being able to tell you about trap representations and similar trivia
and thus obviously has a mind for useless trivia, or someone who's
successfully written complex pieces of software that are used by
many people throughout the world?

(*) Or wanted to amuse the class with discussions of Shakespeare and/or
dirty underware...

P.S. On an an entirely different (and non-ironic) note, I have come to
the conclusion that this newsgroup isn't about C (of course that is
obvious), but rather, about *teaching* C. Think of this as like a
"teacher's college", where people get together to discuss how best to
teach something. As I've said before, the regs are really just
frustrated (and/or, possibly, burned-out) teachers.

On 9 Feb, 02:01, Richard <rgrd...@gmail.com> wrote:
> Keith Thompson <ks...@mib.org> writes:

<snip>

> > Yes, 0 is both an integer constant and a null pointer constant. *I
> > think pete's point (which I agree with) is that 0 is a null pointer
> > constant (or at least is "called" a null pointer constant) regardless
> > of the context in which it appears. *The 0 in:
> > * * int x = 0;
> > is by definition a null pointer constant, even though it's not
> > converted to a pointer type.
>
> Never was I so confused.
>
> I now discover
>
> char *p = 0; /* is the preferred way to create a null pointer +/
>
> And since 0 converts to false in a boolean expression then
>
> if(p){
>
> }
>
> is perfectly valid and the NULL check is completely irrelevant since the
> internal representation does not come into it. The 0 value is all that
> matters.

ah, but I believe (meaning I can' remember where I read it)
that this is problematic

assert (p);

that it needs to be replaced with

assert (p != 0);

to be safe


> Which is brilliant since this is how I treated ptrs for years before
> getting quite a nasty shock in c.l.c where I was told I was being
> sloppy.



--
Nick Keighley

Ben Bacarisse <> writes:

> Richard <rgrdev_@gmail.com> writes:
>
>> Keith Thompson <kst-> writes:
>>
>>> Ben Bacarisse <> writes:
>>>> pete <> writes:
>>>>> Stephen Sprunk wrote:
>>>>>> Malcolm McLean wrote:
>>> [...]
>>>>>>> Surely there is some rule that NULL can be used as the null pointer
>>>>>>> constnant, in all contexts?
>>>>>>
>>>>>> Nope. NULL is allowed to be defined as 0, in which case it only
>>>>>> becomes a null pointer constant when converted to a pointer; in
>>>>>> other contexts, it's simply an integer.
>>>>>
>>>>> 0 is a null pointer constant. That's all, no context.
>>>>>
>>>>> N869
>>>>> 6.3.2.3 Pointers
>>>>> [#3] An integer constant expression with the value 0, or
>>>>> such an expression cast to type void *, is called a null
>>>>> pointer constant.
>>>>
>>>> It is also an integer constant or 6.3.2.3 would not apply. It is
>>>> clearly both at the same time so why do you seem to be suggesting that
>>>> context does not matter?
>>>
>>> Yes, 0 is both an integer constant and a null pointer constant. I
>>> think pete's point (which I agree with) is that 0 is a null pointer
>>> constant (or at least is "called" a null pointer constant) regardless
>>> of the context in which it appears. The 0 in:
>>> int x = 0;
>>> is by definition a null pointer constant, even though it's not
>>> converted to a pointer type.
>>
>> Never was I so confused.
>
> Yes, there is still some confusion.
>
>> I now discover
>>
>> char *p = 0; /* is the preferred way to create a null pointer +/
>
> not everyone prefers it, but some do.
>
>> And since 0 converts to false in a boolean expression then
>>
>> if(p){
>> }
>>
>> is perfectly valid
>
> This is valid but not because of 0 converting to false in a boolean
> expression. At least, that phrase has enough vague parts to it that
> it is not clear what you mean.
>
> In the "if" you wrote p is not converted. An 'if' is defined in terms
> of the expression comparing equal (or not equal) to 0. When a pointer
> is compared to 0 it is the 0 that gets converted to a null pointer.
> This is why the test is safe and correct even when a null pointer has
> a representation that is not all bit zero.
>
>> and the NULL check is completely irrelevant since the
>> internal representation does not come into it.
>
> I can't follow this at all. The internal representation is what
> determines (sometimes rather obliquely) the value of p so it does come
> into it. What matters is whether p compares equal to a null pointer
> of the same type.
>
> What do you mean by the NULL check? It is guaranteed that given char *p:
>
> if (p)
> if (p == 0)
> if (p == NULL)
>
> are all the same.

They are? :-; I don't think so but I know what you meant.

>
>> The 0 value is all that matters.
>
> It is whether the pointer is or is not a null pointer that matters. I
> am not sure if that is what you mean by "the 0 value". 0 is both a
> pointer value and an integer value and C can't compare these two
> without converting one or the other. Everything is designed to work
> if the conversion goes one way:
>
> if (p) => if (p == 0) => 0 converts to a null pointer
>
> but it may not work if you force the conversion the wrong way:
>
> if ((int)p) => if ((int)p == 0) => 0 taken to be an int
>
> what happens here is implementation defined and a null pointer may not
> convert to (int)0.

I'll clarify - its irrelevant compared to some doctrine because you
simply do not need the check. When you assign 0 to p it is NULL. And the
small core that have said here in the past that you SHOULD compare to NULL
were not correct.

e.g

if(p=malloc(X)){
/* is perfectly sound and what I have done for years */
}

In article <gmp1h7$k46$>,
Richard <rgrdev_@gmail.com> wrote:
....
>I have run large C projects. And the core clique would not be allowed 10
>miles from any of them. Especially Falconer. Can you image them rubbing
>their beards in technical meetings and acting all confused as someone
>sketches out a program flow and says "we pass a reference to the huge
>data block here" ....

Indeed. Quite.

"He who can, does. He who can't, teaches. He who can't teach, becomes
a CLC reg."