Pointer to int, implicit conversion

[Rakesh UV]

Re: Pointer to int, implicit conversion



On Nov 21, 6:27 pm, James Kuyper <jameskuy...@ve rizon.netwrote:

Rakesh UV wrote:

On Nov 21, 9:36 am, James Kuyper <jameskuy...@ve rizon.netwrote:

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.

>

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

>

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

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.
>

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

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.

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??

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

>

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]

Re: Pointer to int, implicit conversion

In article
<1ab20b51-b43d-420a-8f8d-d0357029dd7f@w3 4g2000hsg.googl egroups.com>,
Rakesh UV <uvrakesh@gmail .comwrote on Thursday 22 Nov 2007 10:58 am:

>
>
On Nov 21, 6:27 pm, James Kuyper <jameskuy...@ve rizon.netwrote:

>Rakesh UV wrote:

On Nov 21, 9:36 am, James Kuyper <jameskuy...@ve rizon.netwrote:
>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.

>>

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

>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

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

<snip>

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]

Re: Pointer to int, implicit conversion

Rakesh UV wrote:

>
On Nov 21, 6:27 pm, James Kuyper <jameskuy...@ve rizon.netwrote:

>Rakesh UV wrote:

>>On Nov 21, 9:36 am, James Kuyper <jameskuy...@ve rizon.netwrote:
>>>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
>>>Conditiona ls 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

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

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

>>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.
>>

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.

>>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.

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??

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 .

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

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.

>What assumption are you talking about?

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]

Re: Pointer to int, implicit conversion

On Nov 22, 6:12 pm, James Kuyper <jameskuy...@ve rizon.netwrote:

Rakesh UV wrote:
>

On Nov 21, 6:27 pm, James Kuyper <jameskuy...@ve rizon.netwrote:

Rakesh UV wrote:
>On Nov 21, 9:36 am, James Kuyper <jameskuy...@ve rizon.netwrote:
>>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
>>Conditional s 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

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

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

>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.

>

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.
>

>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.

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??

>
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.
>

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

... 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 .
>

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

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.
>

What assumption are you talking about?

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?

[CBFalconer]

Re: Pointer to int, implicit conversion

Rakesh UV wrote:

James Kuyper <jameskuy...@ve rizon.netwrote:
>

.... snip ...

>

>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

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.htm l>
<http://cfaj.freeshell. org/google/ (taming google)
<http://members.fortune city.com/nnqweb/ (newusers)



--
Posted via a free Usenet account from http://www.teranews.com