«

Why (type*)pointer isn't equal to *(type**)pointer,

In the code snippet, it shows that:
(int *) == (int **) ,
(int *) != (*(int **)) .

Does type-casting change the address? or doesn't type-casting do
anything?

1 int main(void)
2 {
3 char ch;
4 int *p;
5 int *p2;
6 int *p3;
7
8 ch = 'c';
9 p = (int *)(&ch);
10 p2 = *(int **)(&ch);
11 p3 = (int **)(&ch);
12
13 printf("%c", *p);
14 printf("%c", *p2); /* error in de-reference */
15 printf("%c", *p3);
16
17 return 0;
18 }
19
~
~

Thank you

lovecreatesbeauty

lovecreatesbeauty wrote:
> Why (type*)pointer isn't equal to *(type**)pointer,
>
> In the code snippet, it shows that:
> (int *) == (int **) ,
> (int *) != (*(int **)) .
>
> Does type-casting change the address? or doesn't type-casting do
> anything?
>
> 1 int main(void)
> 2 {
> 3 char ch;
> 4 int *p;
> 5 int *p2;
> 6 int *p3;
> 7
> 8 ch = 'c';
> 9 p = (int *)(&ch);
> 10 p2 = *(int **)(&ch);

Your are casting to a pointer to pointer to int and dereferencing the
result, which will be 'c' and garbage.

Ian

lovecreatesbeauty wrote:
> Why (type*)pointer isn't equal to *(type**)pointer,

Well, the main reason is that the first does not dereference the
pointer, but the second does. You can't possibly expect two
expressions to have the same value if one dereferences a pointer
and the other one does not.

- Logan

Yes, I can abstract the first byte among the 4 bytes of the int. This
kind of type-casting is normal and occurs frequently, I think.

Ian wrote:
>
> Your are casting to a pointer to pointer to int and dereferencing the
> result, which will be 'c' and garbage.
>
> Ian

Thank you.

But I think (type**)pointer is a double pointer, *(type**)pointer is a
single pointer after de-reference (type**)pointer and is equal to
(type*)pointer, right? I'm so confused on this.

Logan Shaw wrote:
> lovecreatesbeauty wrote:
> > Why (type*)pointer isn't equal to *(type**)pointer,
>
> Well, the main reason is that the first does not dereference the
> pointer, but the second does. You can't possibly expect two
> expressions to have the same value if one dereferences a pointer
> and the other one does not.
>
> - Logan

lovecreatesbeauty said:

> Why (type*)pointer isn't equal to *(type**)pointer,
>
> In the code snippet, it shows that:

In the code snippet, the behaviour is undefined, because you call a variadic
function without a valid prototype in scope. Fix that by adding:

#include <stdio.h>

> (int *) == (int **) ,
> (int *) != (*(int **)) .
>
> Does type-casting change the address? or doesn't type-casting do
> anything?

Casting is an explicit conversion from one type to another. Whether this is
meaningful depends on the situation. So let's look at the situation.

> 1 int main(void)
> 2 {
> 3 char ch;
> 4 int *p;
> 5 int *p2;
> 6 int *p3;
> 7
> 8 ch = 'c';
> 9 p = (int *)(&ch);

The Standard (I'm actually using a C89 draft here - caveat lector) says: "A
pointer to an object or incomplete type may be converted to a pointer to a
different object type or a different incomplete type. The resulting pointer
might not be valid if it is improperly aligned for the type pointed to. It
is guaranteed, however, that a pointer to an object of a given alignment
may be converted to a pointer to an object of the same alignment or a less
strict alignment and back again; the result shall compare equal to the
original pointer."

In this case, the pointer &ch is converted to int *, but there is no
guarantee that a char is aligned in a manner proper to int. So the pointer
is (at least potentially) invalid, and the code is therefore not portable.

> 10 p2 = *(int **)(&ch);

The same applies, so again this is not portable C.

> 11 p3 = (int **)(&ch);

And again.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On 13 Jan 2006 23:15:06 -0800, in comp.lang.c , "lovecreatesbeauty"
<> wrote:

>Why (type*)pointer isn't equal to *(type**)pointer,

it is, if you do it right. In this case however, you're converting
between different types of pointer which may not work since different
pointer types may be stored differently (alignment, size, bitpattern
etc)..

> 1 int main(void)

don't put line numbers in code snippets, I don't plan to retype your
code to test any suggestions I may have. And you may have already had
to, so you may have introduced errors en route.

> 2 {
> 3 char ch;
> 4 int *p;

> 9 p = (int *)(&ch);

This casts a char* into an int*.
int* and char* are rather different pointer types. Converting one into
the other may not work but often will.

> 5 int *p2;
> 10 p2 = *(int **)(&ch);

This casts a char* into an int**, then dereferences it.
int** and char* are definitely different pointer types, converting one
into the other is almost certain to do strange things.

> 13 printf("%c", *p);
> 14 printf("%c", *p2); /* error in de-reference */

you won't get a compile error here provided you #include stdio.h

The result however may be garbage, or crash your application.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

lovecreatesbeauty wrote:
> Thank you.
>
> But I think (type**)pointer is a double pointer, *(type**)pointer is a
> single pointer after de-reference (type**)pointer and is equal to
> (type*)pointer, right? I'm so confused on this.

Ah, I think I may understand the confusion now. Typecasting does not
change what a pointer points to. Ultimately, a pointer is just an
address (at least on most machines) -- something that could be loaded
into an address register. Casting it to a different type does not
change the address. In other words, casting does not change the
value of the pointer. It just changes data structures that the
compiler uses (at compile time) what it should expect to find at
that address.

So, (type**)pointer has a type that indicates it's a pointer to a pointer.
But its value remains the same as without the typecast. The compiler
doesn't do any extra work to make sure the value is consistent with the
address. Only the "&" and "*" operators do that. (Well, and the []
operator.)

- Logan

Mark McIntyre <> writes:
> On 13 Jan 2006 23:15:06 -0800, in comp.lang.c , "lovecreatesbeauty"
> <> wrote:
>
>>Why (type*)pointer isn't equal to *(type**)pointer,
>
> it is, if you do it right. In this case however, you're converting
> between different types of pointer which may not work since different
> pointer types may be stored differently (alignment, size, bitpattern
> etc)..

For certain values of "right". Apart from type compatibility, one
expression dereferences the pointer and the other one doesn't. They
can be equal only if "pointer" happens to point to itself.

>
>> 1 int main(void)
>
> don't put line numbers in code snippets, I don't plan to retype your
> code to test any suggestions I may have. And you may have already had
> to, so you may have introduced errors en route.

Actually, it looks like a copy-and-paste from a vi editor session with
line numbering enabled (":set number"); the trailing '~' characters
are a clue. But yes, line numbers in posted code snippets are a bad
idea. If you want to refer to lines by number, add a comment:

int main(void) /* line 1 */

>> 2 {
>> 3 char ch;
>> 4 int *p;
>
>> 9 p = (int *)(&ch);
>
> This casts a char* into an int*.
> int* and char* are rather different pointer types. Converting one into
> the other may not work but often will.

It could cause alignment problems (int typically has stricter
alignment requirements than char). The problem might not show up in
this case because the compiler is likely to align ch on a word
boundary, but it's a bad idea in general unless you're *sure*
the alignment will be ok.

--
Keith Thompson (The_Other_Keith) kst- <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.

On Sat, 14 Jan 2006 20:11:44 GMT, in comp.lang.c , Keith Thompson
<kst-> wrote:

>Mark McIntyre <> writes:
>> On 13 Jan 2006 23:15:06 -0800, in comp.lang.c , "lovecreatesbeauty"
>> <> wrote:
>>
>> don't put line numbers in code snippets, I don't plan to retype your
>> code to test any suggestions I may have. And you may have already had
>> to, so you may have introduced errors en route.
>
>Actually, it looks like a copy-and-paste from a vi editor session with
>line numbering enabled (":set number");

hadn't thought of that.

>the trailing '~' characters are a clue.

didn't see any in my version of the post, maybe Agent hid them or
something.
Mark McIntyre
--

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----