Pointer to int, implicit conversion

[Tomás Ó hÉilidhe]

[Please forgive the introduction which talks about C++ rather than C, but
I'd just like to explain how I came to be writing if(p) before I go on to
tackle C-specific issues]

Coming originally from C++, I used to do the likes of the following,
using a pointer in a conditional:


void Func(int *p)
{
if (p)
{
*p++ = 7;
*p++ = 8;
}
}

In C++, the type of conditional expressions is bool. When a pointer
is converted to bool, it becomes false if it was a null pointer, true
otherwise. (Let's not get into the issue of whether a pointer to one past
the last element of an array can compare equal to null )

Now writing C code, I stopped and paused for a moment today when I
wrote code like that above. It looks to me, that, in the above code, the
pointer would be converted to an int before it would be evaluated by "if".

The compiler I'm using on the machine beside me is Microsoft Visual
Studio, so it's by no means guaranteed to be 100% compliant to any C
Standard. Anyway, it accepts the above function with zero errors and zero
warning. (And yes it's in C mode, not C++ mode).

But my question is:

1) Should a Standard-compliant compiler accept an implicit conversion
from pointer type to int? (as in "if (p)")
2) If so, what exactly is supposed to happen? Do null pointers become
zero while every other address becomes 1? Somehow I doubt that. My first
guess would be that the Standard doesn't define the behaviour of
converting pointers to integer types.

By the way, I'm aware that the inversion operator, i.e. !, turns a
null pointer into 1 and every other pointer into 0, but I'm talking
specifically about a bare naked pointer without an operator applied.

And yes, I'm fully aware that I can replace if (p) with if (!!p).

The exact code that had me thinking about this was:

assert(p);

I had a function which took a pointer and asserted straight away that
it actually pointed to something. When I switched to a different compiler
on a different machine, I got an error telling me there's no implicit
conversion from pointer to integer type (as I would hope!).

I think I can recall hearing some time ago that the argument to
assert MUST be of type int. Is this true? Should I be writing:

assert(!!p);

And again, what's supposed to happen when I do assert(p)? Is the
pointer converted to an int, and then the int evaluated to see if it's
true or false? If so, then what value does the resultant int have... ? My
guess is that it's undefined by the Standard.

 

[Francine.Neary]

1) Should a Standard-compliant compiler accept an implicit conversion
from pointer type to int? (as in "if (p)")
2) If so, what exactly is supposed to happen? Do null pointers become
zero while every other address becomes 1? Somehow I doubt that. My first
guess would be that the Standard doesn't define the behaviour of
converting pointers to integer types.

You've asked question 5.3 of the C FAQ. <http://c-faq.com/null/
ptrtest.html>

 

[Tomás Ó hÉilidhe]

Francine.Neary:

You've asked question 5.3 of the C FAQ. <http://c-faq.com/null/
ptrtest.html>

Thanks for the link. There's a particular part I want to inquire
about:

-- beginning --
When C requires the Boolean value of an expression, a false value is
inferred when the expression compares equal to zero, and a true value
otherwise. That is, whenever one writes

if(expr)

where ``expr'' is any expression at all, the compiler essentially acts as
if it had been written as

if((expr) != 0)

--

Until now, I had thought that if, while and the middle part of a for
loop all took an "argument" whose type was int. Therefore I _thought_
that the following would always be identical:

if (a)

and:

if ((int)a)

, regardless of the type of the expression int. Putting a little more
thought into it though, I realised I violate this train of thought all
the time:

unsigned i = UINT_MAX;

if (i)

Of course, the behaviour is implementation-defined when you assign
too-big-of-a-number to an int, so we can't say for sure whether (int)i
would be true or false, but we _do_ know for sure that i is true.

So should I just forget the idea altogether that conditionals are of
type int in C? I realise that the operators ==, >, !=, etc. all evaluate
to an int, but I suppose that doesn't have to mean that if, while and the
middle part of a for have to take an int argument.

So basically, the conditionals take the value, regardless of its
type, and return false if it's zero (including a null pointer), otherwise
true. Looks like I can just keep going exactly how I was doing things in C
++. :-D

If I'm mistaken, please throw a pie in my face! One more thing, can
someone please tell me whether I have to give an int value to assert?

 

[Flash Gordon]

Tomás Ó hÉilidhe wrote, On 20/11/07 22:36:

Until now, I had thought that if, while and the middle part of a for
loop all took an "argument" whose type was int. Therefore I _thought_
that the following would always be identical:

if (a)

and:

if ((int)a)

<snip reasons this might be wrong>

You thought wrong for, amongst other things, the reasons you went on to
specify.

So should I just forget the idea altogether that conditionals are of
type int in C? I realise that the operators ==, >, !=, etc. all evaluate
to an int, but I suppose that doesn't have to mean that if, while and the
middle part of a for have to take an int argument.

Yes, forget that idea as it is definitely wrong.

So basically, the conditionals take the value, regardless of its
type, and return false if it's zero (including a null pointer), otherwise
true. Looks like I can just keep going exactly how I was doing things in C
++. :-D

I believe the rules are the same as for C++ because I believe that C++
inherited them from C.

If I'm mistaken, please throw a pie in my face!

Can't we throw one anyway?

One more thing, can
someone please tell me whether I have to give an int value to assert?

I can't remember the exact rule, but I believe that in C89/C90/C95 (the
most commonly fully implemented versions of the standard) you are not
allowed to assert on the value of a pointer directly. I believe this
changed in C99.

 

[Jack Klein]

Francine.Neary:



Thanks for the link. There's a particular part I want to inquire
about:

-- beginning --
When C requires the Boolean value of an expression, a false value is
inferred when the expression compares equal to zero, and a true value
otherwise. That is, whenever one writes

if(expr)

where ``expr'' is any expression at all, the compiler essentially acts as
if it had been written as

if((expr) != 0)

--

Until now, I had thought that if, while and the middle part of a for
loop all took an "argument" whose type was int. Therefore I _thought_
that the following would always be identical:

if (a)

and:

if ((int)a)

, regardless of the type of the expression int. Putting a little more
thought into it though, I realised I violate this train of thought all
the time:

unsigned i = UINT_MAX;

if (i)

Of course, the behaviour is implementation-defined when you assign
too-big-of-a-number to an int, so we can't say for sure whether (int)i
would be true or false, but we _do_ know for sure that i is true.

So should I just forget the idea altogether that conditionals are of
type int in C? I realise that the operators ==, >, !=, etc. all evaluate
to an int, but I suppose that doesn't have to mean that if, while and the
middle part of a for have to take an int argument.

An expression evaluated in a Boolean context in C yields a result of
type int with the value 0 or 1. That has nothing to do with what the
operands are.

For example:

double d1 = 3.9 d2 = 3.1;

if (d1 == d2)
{
/* stuff */
}

I assume that if you wrote the code above, you would be very, very
surprised if the statements designated by /* stuff */ were executed.
Yet if there was an explicit conversion to int, both d1 and d2 would
be truncated to 3, and /* stuff */ would be executed.

So basically, the conditionals take the value, regardless of its
type, and return false if it's zero (including a null pointer), otherwise
true. Looks like I can just keep going exactly how I was doing things in C
++. :-D

Basically, expressions operate on values. If there are multiple
values, rvalues or lvalues, in an expression, the standard promotions
are performed, just as if you perform an operation like addition or
subtraction on two different types.

Based on the as-if rule, of course, Boolean expressions do not
actually have to produce an actual int with a value of 0 or 1. In the
d1 and d2 example above, the compiler generates machine language to do
the comparison and uses some processor specific mechanism to execute
/* stuff */ or jump over it.

On the other hand, if you have code like this (inside a function):

double d1 = /* some value */, d2 = /* some value */;
int equal;

/* some operations that might modify the values of */
/* d1 and/or d2 */

equal = (d1 == d2);

....then the program must generate code to produce an actual int value
of 0 or 1 and store it in "equal". Assuming that it the value of
equal is later used, so it can't be optimized away.

If I'm mistaken, please throw a pie in my face! One more thing, can
someone please tell me whether I have to give an int value to assert?

Flash's memory on this question is correct. Prior to C99, the C
standard defined the assert macro to take an int parameter, although
many (perhaps even most) compilers accepted a pointer with an implicit
test against 0.

From 1999 on, the C standard allows any scalar type for the
expression, meaning integer types, floating point types, and pointers.

--
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.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[James Kuyper]

Tomás Ó hÉilidhe wrote:
....

So basically, the conditionals take the value, regardless of its
type, and return false if it's zero (including a null pointer), otherwise

Conditionals do not return false (or true); they result in one part of
the code or another being executed. They do this based upon whether or
not the conditional expression compares equal to 0. That's not the same
as saying it's the same as 0. An expression can be zero only if it has
arithmetic type. Pointers do not have an arithmetic type, so it's not
meaningful to say that they are 0, but because of the rules for null
pointer constants, pointers compare equal to zero when they are null.

 

[Rakesh UV]

Tomás Ó hÉilidhe wrote:

...


Conditionals do not return false (or true); they result in one part of
the code or another being executed. They do this based upon whether or
not the conditional expression compares equal to 0. That's not the same
as saying it's the same as 0. An expression can be zero only if it has
arithmetic type. Pointers do not have an arithmetic type, so it's not
meaningful to say that they are 0, but because of the rules for null
pointer constants, pointers compare equal to zero when they are null.

If You are working in a 64 bit machine then it would make a difference
otherwise if(p) doesn't have any issue in 32 bit machine
If we really want to use a language efficiently and safely, Then we
should
try to express our intension much clearly and specifically in C
language.
instead of allowing the compiler to assume thing, this a very bad
Practice.
This discussion was not useful and was repitative

RUV

 

[Chris Torek]

Until now, I had thought that if, while and the middle part of a for
loop all took an "argument" whose type was int. ...

If they were functions, they would take actual arguments, and --
assuming they were not something peculiar like printf(), i.e.,
not a "variadic" function -- the argument would have to have a
fixed type. But they are not functions; they are keywords.

The way to think about them, in my opinion -- which I admit is
a bit colored by past work on compilers -- is to say that they
take an "expression tree node", which is a compiler internal
data structure, and start by examining the type of this node.
If the type is "pointer to T" (where T is any valid type -- if
T were not a valid type we would not have gotten to this point
inside the compiler in the first place), they generate code to
compare the pointer against a null pointer of that same type.

If the expression tree node has some other type, such as "double",
the compiler generates a comparison against 0.0, or whatever else
is appropriate. If the node has a type that is already known to
be "sufficiently boolean", whatever that means given the compiler
and the target architecture, the compiler may not have to generate
any code at all. (As an example of the latter, if the node is not
a simple variable, but instead is something like (COMPAREOP x y),
the compiler need only ask its expression-evaluator to generate
the appropriate comparison-for-condition-codes sequence, then emit
the appropriate branch. This assumes the target CPU has condition
codes, of course.)

 

[santosh]

If You are working in a 64 bit machine then it would make a difference
otherwise

What would make a difference? Comparing pointers against literal zero?
If so, I can't see why?

if(p) doesn't have any issue in 32 bit machine

I believe it should be issue-free on any N-bit system that supports
Standard C.

If we really want to use a language efficiently and safely, Then we
should try to express our intension much clearly and specifically in C
language. instead of allowing the compiler to assume thing,

I agree here. Compilers can handle obscure and "clever" constructs and
obfuscated code, but the maintenance programmer may not do so. High
level language source is for human consumption, otherwise we might as
well program in machine code.

this a very bad Practice.
This discussion was not useful and was
repitative

It's likely to be useful to lurkers and newbies, who are perhaps the
greatest beneficiaries of most newsgroups.

 

[Tomás Ó hÉilidhe]

Jack Klein:

For example:

double d1 = 3.9 d2 = 3.1;

if (d1 == d2)
{
/* stuff */
}

I assume that if you wrote the code above, you would be very, very
surprised if the statements designated by /* stuff */ were executed. Yet
if there was an explicit conversion to int, both d1 and d2 would be
truncated to 3, and /* stuff */ would be executed.

That would never happen. If I had:

void Func(int);

and called it as follows:

Func( 2.0 * 3.7 );

, then the entire expression would be converted to int _after_ it's
evaluated. It won't becomes "2 * 3".

(Somehow I think we misunderstand each other here because I've read a few
of your other posts and you seem to know your stuff, so it's surprising
to me that you'd come out with something like this).

 

[Philip Potter]

Jack Klein:


That would never happen. If I had:

You're right, but the following demonstrates the same point:

if(d1 - d2) /* same values as before */
{
/* stuff */
}

i.e. if(0.8) is true because 0.8 != 0.0; it is not false because
(int)0.8 == 0.

 

[James Kuyper]

If You are working in a 64 bit machine then it would make a difference

Explain, please?

otherwise if(p) doesn't have any issue in 32 bit machine

As far as I know, the only issue with if(p) is whether or not the
programmer correctly understands that it is identical in meaning to
if(p!=0). I don't see how that depends upon whether the machine is 32
bits or 64 bits.

If we really want to use a language efficiently and safely, Then we
should
try to express our intension much clearly and specifically in C
language.

If(p) seems perfectly clear to me.

instead of allowing the compiler to assume thing, this a very bad
Practice.

What assumption are you talking about?

 

[Richard]

Jack Klein:



That would never happen. If I had:

void Func(int);

and called it as follows:

Func( 2.0 * 3.7 );

, then the entire expression would be converted to int _after_ it's
evaluated. It won't becomes "2 * 3".

(Somehow I think we misunderstand each other here because I've read a few
of your other posts and you seem to know your stuff, so it's surprising
to me that you'd come out with something like this).

You appear to have missed the bit where he said

"if there was an explicit conversion to int" where I assume Jack was
referring to d1 and d2 being explicitly cast. "if" being the operative
word here.

 

[Tomás Ó hÉilidhe]

Richard:

You appear to have missed the bit where he said

"if there was an explicit conversion to int" where I assume Jack was
referring to d1 and d2 being explicitly cast. "if" being the operative
word here.

I didn't miss it. Even if there were a conversion to int, it would be:

(int)(d1 == d2)

rather than:

(int)d1 == (int)d2

 

[Jack Klein]

Richard:



I didn't miss it. Even if there were a conversion to int, it would be:

(int)(d1 == d2)

rather than:

(int)d1 == (int)d2

Then we were misunderstanding each other, my example assumed you were
thinking of the latter, when apparently you were not.

--
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.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Rakesh UV]

the 64 pit machine
Explain, please?

This is the output i got from a program which was written for size of
int, char, long, pointer etc

sizeof char = 1 , shortint = 2 , int 4 , long = 8 , pointer = 8

There is a difference in int and pointer size

As far as I know, the only issue with if(p) is whether or not the
programmer correctly understands that it is identical in meaning to
if(p!=0). I don't see how that depends upon whether the machine is 32
bits or 64 bits.

would there be any probablity to get unexpected result here, at any
point of time??does our intention match with the compiler's ??

If(p) seems perfectly clear to me.

does the compiler checks whether the 64 bit value is zero or the 32
bit value is zero??
should the compiler see 'p' as pointer or an integer.Does this really
make any difference??is the output dependend upon the mercy of compiler??

What assumption are you talking about?

i am thinking about the loss of few bytes which would make difference

 

[santosh]

This is the output i got from a program which was written for size of
int, char, long, pointer etc

sizeof char = 1 , shortint = 2 , int 4 , long = 8 , pointer = 8

There is a difference in int and pointer size

Nevertheless if (p) for 'p' of any scalar type should work as expected.

does the compiler checks whether the 64 bit value is zero or the 32
bit value is zero??
should the compiler see 'p' as pointer or an integer.Does this really
make any difference??

When you compare a pointer against a literal zero that zero is converted
to a null pointer value of the appropriate type (and hence size) to
enable the comparison to proceed.

<snip>

 

[James Kuyper]

This is the output i got from a program which was written for size of
int, char, long, pointer etc

sizeof char = 1 , shortint = 2 , int 4 , long = 8 , pointer = 8

There is a difference in int and pointer size

Yes, I know that. But what does the difference have to do with the
interpretation of conditionals in C?

would there be any probablity to get unexpected result here, at any
point of time??

There's certainly a possibility; but I wouldn't call it a probability.
There's at least three ways to get unexpected results: the
implementation is non-conforming, the program has undefined behavior, or
the programmer doesn't understand correctly what he should be expecting.
But there's no distinction between 32 bit and 64 bit machines in any of
those cases.

does our intention match with the compiler's ??
does the compiler checks whether the 64 bit value is zero or the 32
bit value is zero??

That depends. If p has a 64 bit arithmetic type, it checks whether the
64 bit value represented by that object is 0. If p has a 32 bit
arithmetic type, it checks whether the 32 bit value represented by that
object is zero.

Since in context, I was intending for p to represent a pointer type, it
doesn't check whether the value of p is zero, because 0 isn't a value
that a pointer object can represent. Instead, it checks whether the
pointer compares equal to 0, which happens if and only if p represents a
null pointer. If p is a 64 bit pointer, it checks whether those 64 bits
represent a null pointer. If p is a 32 bit pointer, it checks whether
those 32 bits represent a null pointer.

should the compiler see 'p' as pointer or an integer. ...

Well, if p is declared as a pointer, the compiler had better see 'p' as
a pointer if it wishes to claim conformance with the C standard.

... Does this really
make any difference??

Certainly. If p were an integer type, there would be only one bit
pattern (ignoring padding bits) whose value compares equal to 0 for 2's
integer types, and that bit pattern would have all non-padding bits set
to 0. For 1's complement and sign-magnitude integer types, there would
be at most two different bit patterns (ignoring padding bits), one of
them with all-bits-zero, representing values that compare equal to zero

On the other hand, since p has a pointer type, there can be as many
different representations of a null pointer as the implementation finds
convenient. All-bits-zero doesn't have to be one of those representations.

is the output dependend upon the mercy of compiler??

No. If you set an arithmetic variable to a non-zero value, or a pointer
to a non-null pointer value, the if-clause of if(p) executes. If you set
an arithmetic variable to zero, or a pointer to a null pointer value,
then the else-clause, if any , is what executes.

i am thinking about the loss of few bytes which would make difference

Yes, but what assumption are you talking about that would result in the
loss of a few bytes? What plausible assumption would cause an
implementation to use only 32 bits of an object, when the implementors
know (since they themselves defined it that way) that it actually has a
64 bit type?

 

[Rakesh UV]

Yes, I know that. But what does the difference have to do with the
interpretation of conditionals in C?



There's certainly a possibility; but I wouldn't call it a probability.
There's at least three ways to get unexpected results: the
implementation is non-conforming, the program has undefined behavior, or
the programmer doesn't understand correctly what he should be expecting.
But there's no distinction between 32 bit and 64 bit machines in any of
those cases.



That depends. If p has a 64 bit arithmetic type, it checks whether the
64 bit value represented by that object is 0. If p has a 32 bit
arithmetic type, it checks whether the 32 bit value represented by that
object is zero.

Since in context, I was intending for p to represent a pointer type, it
doesn't check whether the value of p is zero, because 0 isn't a value
that a pointer object can represent. Instead, it checks whether the
pointer compares equal to 0, which happens if and only if p represents a
null pointer. If p is a 64 bit pointer, it checks whether those 64 bits
represent a null pointer. If p is a 32 bit pointer, it checks whether
those 32 bits represent a null pointer.


Well, if p is declared as a pointer, the compiler had better see 'p' as
a pointer if it wishes to claim conformance with the C standard.

Your are exactly correct, i saw the assembly code generated by the
compiler,
There is no loss of bytes basically, I was actually trying to the
show that if
everything inside "if(p)" would be upgraded to an int and then it is
tested as
zero or nonzero(as per the first mail).Then there is a possiblity of
loss of
memory

 

[CBFalconer]

.... snip ...


Your are exactly correct, i saw the assembly code generated by the
compiler, There is no loss of bytes basically, I was actually
trying to the show that if everything inside "if(p)" would be
upgraded to an int and then it is tested as zero or nonzero(as per
the first mail). Then there is a possiblity of loss of memory

You generated a message of roughly 140 lines for these 5 lines of
answer, which were also over long (and thus awkwardly wrapped).
Please snip properly (see the links below) and maintain your line
length at 72 or less. 67 is better.

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/> (taming google)
<http://members.fortunecity.com/nnqweb/> (newusers)