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

Discussion in 'C Programming' started by lovecreatesbeauty, Jan 14, 2006.

  1. 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, Jan 14, 2006
    #1
    1. Advertising

  2. lovecreatesbeauty

    Ian Guest

    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
    Ian, Jan 14, 2006
    #2
    1. Advertising

  3. lovecreatesbeauty

    Logan Shaw Guest

    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
    Logan Shaw, Jan 14, 2006
    #3
  4. 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
    lovecreatesbeauty, Jan 14, 2006
    #4
  5. 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, Jan 14, 2006
    #5
  6. 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)
    Richard Heathfield, Jan 14, 2006
    #6
  7. 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 =----
    Mark McIntyre, Jan 14, 2006
    #7
  8. lovecreatesbeauty

    Logan Shaw Guest

    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
    Logan Shaw, Jan 14, 2006
    #8
  9. 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) <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.
    Keith Thompson, Jan 14, 2006
    #9
  10. On Sat, 14 Jan 2006 20:11:44 GMT, in comp.lang.c , Keith Thompson
    <> 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 =----
    Mark McIntyre, Jan 14, 2006
    #10
  11. Groovy hepcat Richard Heathfield was jivin' on Sat, 14 Jan 2006
    09:17:41 +0000 (UTC) in comp.lang.c.
    Re: Why (type*)pointer isn't equal to *(type**)pointer?'s a cool
    scene! Dig it!

    >lovecreatesbeauty said:
    >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.


    Yes, and this is even worse still. The OP is actually dereferencing
    the pointer here. And you know what happens when one dereferences a
    pointer pointing at an object of an incompatible type. BANG! Undefined
    behaviour!

    --

    Dig the even newer still, yet more improved, sig!

    http://alphalink.com.au/~phaywood/
    "Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
    I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
    Peter Shaggy Haywood, Jan 17, 2006
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    877
    Mark Rae
    Dec 21, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,805
    Smokey Grindel
    Dec 2, 2006
  3. aling
    Replies:
    8
    Views:
    943
    Jim Langston
    Oct 20, 2005
  4. PerlFAQ Server
    Replies:
    0
    Views:
    585
    PerlFAQ Server
    Feb 11, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    583
    PerlFAQ Server
    Mar 9, 2011
Loading...

Share This Page