Casting char* to int*

Discussion in 'C Programming' started by Alex Vinokur, Nov 16, 2007.

  1. Alex Vinokur

    Alex Vinokur Guest

    Alex Vinokur, Nov 16, 2007
    #1
    1. Advertising

  2. Alex Vinokur said:

    > char* pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;


    The cast is meaningless, as is the assignment.

    Don't Do That.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Nov 16, 2007
    #2
    1. Advertising

  3. Alex Vinokur

    Chris Dollin Guest

    Alex Vinokur wrote:

    > char* pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;


    No, we simply shouldn't do the assignment. Or, for that matter, the if.
    Come to think of it, calling a variable `pch` looks a bit odd. I assume
    that `pint` is a variable to cope with transAtlantic variation?

    --
    Chris "drinks halves anyway" Dollin

    Hewlett-Packard Limited registered office: Cain Road, Bracknell,
    registered no: 690597 England Berks RG12 1HN
     
    Chris Dollin, Nov 16, 2007
    #3
  4. Alex Vinokur

    Alex Vinokur Guest

    On Nov 16, 11:32 am, Alex Vinokur <>
    wrote:
    > char* pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;
    >


    Sorry, should be:

    char pch [120];

    // Should we check
    // if (((size_t) pch & 3) == 0)
    // before the following statement ?
    int* pint = (int*) pch;


    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn
     
    Alex Vinokur, Nov 16, 2007
    #4
  5. Alex Vinokur said:

    > On Nov 16, 11:32 am, Alex Vinokur <>
    > wrote:
    >> char* pch [120];
    >>
    >> // Should we check
    >> // if (((size_t) pch & 3) == 0)
    >> // before the following statement ?
    >> int* pint = (int*) pch;
    >>

    >
    > Sorry, should be:
    >
    > char pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;


    As you can see, your correction has a remarkable effect on my reply, which
    becomes:

    The cast is meaningless, as is the assignment.

    Don't Do That.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Nov 16, 2007
    #5
  6. Alex Vinokur

    Chris Dollin Guest

    Alex Vinokur wrote:

    > On Nov 16, 11:32 am, Alex Vinokur <>
    > wrote:
    >> char* pch [120];
    >>
    >> // Should we check
    >> // if (((size_t) pch & 3) == 0)
    >> // before the following statement ?
    >> int* pint = (int*) pch;
    >>

    > Sorry, should be:
    >
    > char pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;


    Same answer: don't /do/ that. Why would you want to? If you want to
    initialise a pointer-to-int, how about initialising it with the
    address of an (some) integer(s)?

    [PS what were you going to do if your suspect conditional wasn't true?]

    --
    Chris "oh noes! characters isn't integers! (fx:dies)" Dollin

    Hewlett-Packard Limited Cain Road, Bracknell, registered no:
    registered office: Berks RG12 1HN 690597 England
     
    Chris Dollin, Nov 16, 2007
    #6
  7. Alex Vinokur

    Mark Bluemel Guest

    Alex Vinokur wrote:

    > char pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;


    What are you trying to achieve? If you want to handle ints, why have a
    byte array?

    Oh, and why are you crossposting - which language do you want to use?

    (I'm only going to reply in comp.lang.c)
     
    Mark Bluemel, Nov 16, 2007
    #7
  8. Alex Vinokur

    Joe Wright Guest

    Alex Vinokur wrote:
    > char* pch [120];
    >
    > // Should we check
    > // if (((size_t) pch & 3) == 0)
    > // before the following statement ?
    > int* pint = (int*) pch;
    >


    pch is not a char pointer. It is an array [120] of pointers to char.

    --
    Joe Wright
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
     
    Joe Wright, Nov 17, 2007
    #8
  9. Alex Vinokur

    pete Guest

    Joe Wright wrote:
    >
    > Alex Vinokur wrote:
    > > char* pch [120];
    > >
    > > // Should we check
    > > // if (((size_t) pch & 3) == 0)
    > > // before the following statement ?
    > > int* pint = (int*) pch;


    That would be both a declaration and an object definition,
    but the above line of code, is not a statement.


    > >

    >
    > pch is not a char pointer. It is an array [120] of pointers to char.


    And, prior to being operated on by each cast operator,
    the expression (pch),
    is implicitly converted to type (char **).

    I think Alex is depending on some intimate knowledge
    of a specific C implementation.

    According to the rules of C, whether or not
    int* pint = (int*) pch;
    will work right, depends on size and alignment issues.

    It *cannot* be construed from the C standard, that
    if (((size_t) pch & 3) == 0)
    is sufficient to check for those size and alignment issues.

    --
    pete
     
    pete, Nov 17, 2007
    #9
  10. Alex Vinokur

    Alex Vinokur Guest

    On Nov 16, 12:25 pm, Richard Heathfield <> wrote:
    > AlexVinokursaid:
    >
    >
    >
    >
    >
    > > On Nov 16, 11:32 am,AlexVinokur<>
    > > wrote:
    > >> char* pch [120];

    >
    > >> // Should we check
    > >> // if (((size_t) pch & 3) == 0)
    > >> // before the following statement ?
    > >> int* pint = (int*) pch;

    >
    > > Sorry, should be:

    >
    > > char pch [120];

    >
    > > // Should we check
    > > // if (((size_t) pch & 3) == 0)
    > > // before the following statement ?
    > > int* pint = (int*) pch;

    >
    > As you can see, your correction has a remarkable effect on my reply, which
    > becomes:
    >
    > The cast is meaningless, as is the assignment.
    >
    > Don't Do That.

    The casting or the assignment?

    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn
     
    Alex Vinokur, Nov 19, 2007
    #10
  11. Alex Vinokur said:

    > On Nov 16, 12:25 pm, Richard Heathfield <> wrote:


    <snip>

    >> The cast is meaningless, as is the assignment.
    >>
    >> Don't Do That.

    > The casting or the assignment?


    Both (as in, don't do either of them).

    Instead, re-state the problem at a higher level, and find a better way to
    solve it that doesn't involve spurious assumptions about object
    representation and alignment.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Nov 19, 2007
    #11
  12. Alex Vinokur

    James Kanze Guest

    On Nov 17, 7:03 pm, pete <> wrote:
    > Joe Wright wrote:


    > > Alex Vinokur wrote:
    > > > char* pch [120];


    > > > // Should we check
    > > > // if (((size_t) pch & 3) == 0)
    > > > // before the following statement ?
    > > > int* pint = (int*) pch;


    > That would be both a declaration and an object definition,
    > but the above line of code, is not a statement.


    What is it, then.

    > > pch is not a char pointer. It is an array [120] of pointers
    > > to char.


    > And, prior to being operated on by each cast operator,
    > the expression (pch),
    > is implicitly converted to type (char **).


    > I think Alex is depending on some intimate knowledge
    > of a specific C implementation.


    I think it would be better if he actually told us what he is
    trying to do. I can't see any case where his exact code would
    make sense.

    > According to the rules of C, whether or not
    > int* pint = (int*) pch;
    > will work right, depends on size and alignment issues.


    Amongst other things. Regretfully, Alex cross-posted, and the
    rules for C and for C++ here are subtly different. In C, if pch
    is not correctly aligned for the target type, the behavior is
    undefined; in C++ the results are unspecified, even if the
    alignment is correct. But those are really subtilities: in both
    cases, it's something you don't do except in very low level,
    machine dependent code (in which case, of course, your program
    depends on what the compiler does with it).

    > It *cannot* be construed from the C standard, that
    > if (((size_t) pch & 3) == 0)
    > is sufficient to check for those size and alignment issues.


    It may not even be legal (requiring a compiler diagnostic in
    C++, and resulting in undefined behavior in C). According to
    the relevant standards, the conversion is only legal if size_t
    is large enough to hold the pointer type (and I've used systems
    where size_t was 16 bits, and char* 32, or where size_t was 32
    bits, and char* 48).

    Even when it is legal, the results of the conversion are
    implementation defined. The C++ standard adds the note: "it is
    intended to be unsurprising to those who know the addressing
    structure of the underlying machine", but that's just a note,
    and non-normative. And it really doesn't mean much anyway.
    (FWIW: the low order bits of a byte pointer on a PDP-10 where
    somewhere in the upper half of the word, which means that his
    test wouldn't look at them anyway.)

    In practice, of course, as others have already pointed out:
    what's he going to do if the test fails (as it almost certainly
    will under some conditions)?

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 19, 2007
    #12
  13. Alex Vinokur

    James Kuyper Guest

    James Kanze wrote:
    > On Nov 17, 7:03 pm, pete <> wrote:
    >> Joe Wright wrote:

    >
    >>> Alex Vinokur wrote:
    >>>> char* pch [120];

    >
    >>>> // Should we check
    >>>> // if (((size_t) pch & 3) == 0)
    >>>> // before the following statement ?
    >>>> int* pint = (int*) pch;

    >
    >> That would be both a declaration and an object definition,
    >> but the above line of code, is not a statement.

    >
    > What is it, then.


    A declaration - as he already said. See section 6.8.1p1 of the C
    standard: declarations do not qualify as statements, though they may
    occur inside the block-item-list of a compound-statement (6.8.2p1). I'm
    not absolutely sure, but I believe C++ makes similar distinctions.
     
    James Kuyper, Nov 19, 2007
    #13
  14. Alex Vinokur

    Alex Vinokur Guest

    Casting char* to int* in C

    On Nov 19, 4:08 pm, James Kanze <> wrote:
    > On Nov 17, 7:03 pm, pete <> wrote:
    >
    > > Joe Wright wrote:
    > > >Alex Vinokurwrote:
    > > > > char* pch [120];
    > > > > // Should we check
    > > > > // if (((size_t) pch & 3) == 0)
    > > > > // before the following statement ?
    > > > > int* pint = (int*) pch;

    > > That would be both a declaration and an object definition,
    > > but the above line of code, is not a statement.

    >
    > What is it, then.
    >
    > > > pch is not a char pointer. It is an array [120] of pointers
    > > > to char.

    > > And, prior to being operated on by each cast operator,
    > > the expression (pch),
    > > is implicitly converted to type (char **).
    > > I think Alex is depending on some intimate knowledge
    > > of a specific C implementation.

    >
    > I think it would be better if he actually told us what he is
    > trying to do. I can't see any case where his exact code would
    > make sense.
    >
    > > According to the rules of C, whether or not
    > > int* pint = (int*) pch;
    > > will work right, depends on size and alignment issues.

    >
    > Amongst other things. Regretfully, Alex cross-posted, and the
    > rules for C and for C++ here are subtly different. In C, if pch
    > is not correctly aligned for the target type, the behavior is
    > undefined; in C++ the results are unspecified, even if the
    > alignment is correct. But those are really subtilities: in both
    > cases, it's something you don't do except in very low level,
    > machine dependent code (in which case, of course, your program
    > depends on what the compiler does with it).
    >

    Separated replies have sent to comp.lang.c++ and comp.lang.c


    Here is some program.
    ---------------------------------

    char* pch1 = "String-1";
    char ach2[] = "String-2";

    int main()
    {
    char* pch3 = "String-4";
    char ach4[] = "String-5";
    char* pch5 = malloc (100);

    int* pint1 = (int*)pch1;
    int* pint2 = (int*)ach2;
    int* pint3 = (int*)pch3;
    int* pint4 = (int*)ach4;
    int* pint5 = (int*)pch5;

    return 0;
    }

    ---------------------------------
    What castings in that program are unsafe/safe?


    --
    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn
     
    Alex Vinokur, Nov 19, 2007
    #14
  15. Re: Casting char* to int* in C

    Alex Vinokur said:

    <snip>

    > Here is some program.
    > ---------------------------------
    >
    > char* pch1 = "String-1";
    > char ach2[] = "String-2";
    >
    > int main()
    > {
    > char* pch3 = "String-4";
    > char ach4[] = "String-5";
    > char* pch5 = malloc (100);


    Undefined behaviour (no prototype in scope for malloc, so the compiler
    can't win here). You should have got a diagnostic message for this line.

    > int* pint1 = (int*)pch1;


    unsafe - pch1 might not be aligned properly for ints

    > int* pint2 = (int*)ach2;


    unsafe - ach2 might not be aligned properly for ints

    > int* pint3 = (int*)pch3;


    unsafe - pch3 might not be aligned properly for ints

    > int* pint4 = (int*)ach4;


    unsafe - ach4 might not be aligned properly for ints

    > int* pint5 = (int*)pch5;


    unsafe - pch5 might not even be a valid pointer

    >
    > return 0;
    > }
    >
    > ---------------------------------
    > What castings in that program are unsafe/safe?


    All of them are unsafe.

    Why are you so desperate to cast? Almost all casts are *wrong*.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Nov 19, 2007
    #15
  16. Alex Vinokur

    James Kanze Guest

    On Nov 19, 3:17 pm, James Kuyper <> wrote:
    > James Kanze wrote:
    > > On Nov 17, 7:03 pm, pete <> wrote:
    > >> Joe Wright wrote:


    > >>> Alex Vinokur wrote:
    > >>>> char* pch [120];


    > >>>> // Should we check
    > >>>> // if (((size_t) pch & 3) == 0)
    > >>>> // before the following statement ?
    > >>>> int* pint = (int*) pch;


    > >> That would be both a declaration and an object definition,
    > >> but the above line of code, is not a statement.


    > > What is it, then.


    > A declaration - as he already said. See section 6.8.1p1 of the
    > C standard: declarations do not qualify as statements, though
    > they may occur inside the block-item-list of a
    > compound-statement (6.8.2p1).


    Wierd. I'd never noticed that the C standard redefines
    statement in a non-standard way. The usual definition of the
    word corresponds to what the C standard calls a block-item.

    > I'm not absolutely sure, but I believe C++ makes similar
    > distinctions.


    In C++, the production for "statement" includes the alternative
    declaration-statement.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 20, 2007
    #16
    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. Schnoffos
    Replies:
    2
    Views:
    1,252
    Martien Verbruggen
    Jun 27, 2003
  2. trey

    newbie: char* int and char *int

    trey, Sep 10, 2003, in forum: C Programming
    Replies:
    7
    Views:
    427
    Irrwahn Grausewitz
    Sep 10, 2003
  3. Hal Styli
    Replies:
    14
    Views:
    1,713
    Old Wolf
    Jan 20, 2004
  4. lovecreatesbeauty
    Replies:
    1
    Views:
    1,152
    Ian Collins
    May 9, 2006
  5. gert
    Replies:
    20
    Views:
    1,222
Loading...

Share This Page