468,457 Members | 1,614 Online

# Casting char* to int*

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
Nov 16 '07 #1
14 6024
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
Nov 16 '07 #2
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

Nov 16 '07 #3
On Nov 16, 11:32 am, Alex Vinokur <ale...@users.sourceforge.net>
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

Nov 16 '07 #4
Alex Vinokur said:
On Nov 16, 11:32 am, Alex Vinokur <ale...@users.sourceforge.net>
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
Nov 16 '07 #5
Alex Vinokur wrote:
On Nov 16, 11:32 am, Alex Vinokur <ale...@users.sourceforge.net>
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

Nov 16 '07 #6
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)
Nov 16 '07 #7
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 ---
Nov 17 '07 #8
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
Nov 17 '07 #9
On Nov 16, 12:25 pm, Richard Heathfield <r...@see.sig.invalidwrote:
AlexVinokursaid:

On Nov 16, 11:32 am,AlexVinokur<ale...@users.sourceforge.net>
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
Nov 19 '07 #10
Alex Vinokur said:
On Nov 16, 12:25 pm, Richard Heathfield <r...@see.sig.invalidwrote:
<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
Nov 19 '07 #11
James Kanze wrote:
On Nov 17, 7:03 pm, pete <pfil...@mindspring.comwrote:
>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.
Nov 19 '07 #12
On Nov 19, 4:08 pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 17, 7:03 pm, pete <pfil...@mindspring.comwrote:
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

Nov 19 '07 #13
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
Nov 19 '07 #14
On Nov 19, 3:17 pm, James Kuyper <jameskuy...@verizon.netwrote:
James Kanze wrote:
On Nov 17, 7:03 pm, pete <pfil...@mindspring.comwrote:
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:ja*********@gmail.com
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
Nov 20 '07 #15

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

 231 posts views Thread by Brian Blais | last post: by 14 posts views Thread by mr_semantics | last post: by 44 posts views Thread by Agoston Bejo | last post: by 2 posts views Thread by Alex Vinokur | last post: by 5 posts views Thread by brekehan | last post: by 24 posts views Thread by Francine.Neary | last post: by 17 posts views Thread by sophia.agnes | last post: by 5 posts views Thread by jason.cipriani | last post: by 32 posts views Thread by alex.j.k2 | last post: by 101 posts views Thread by Tinkertim | last post: by reply views Thread by ravipankaj | last post: by reply views Thread by NPC403 | last post: by reply views Thread by slotstar | last post: by reply views Thread by captainhaddock | last post: by 2 posts views Thread by Zeeshan Ahmad | last post: by 1 post views Thread by subhajit12345 | last post: by 1 post views Thread by adamb123 | last post: by 3 posts views Thread by hwsilver | last post: by 1 post views Thread by AlexK987 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.