Casting char* to int*

[Alex Vinokur]

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

[Richard Heathfield]

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

[Chris Dollin]

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

[Alex Vinokur]

On Nov 16, 11:32 am, Alex Vinokur <[e-mail]>
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

[Richard Heathfield]

Alex Vinokur said:

On Nov 16, 11:32 am, Alex Vinokur <[e-mail]>
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

[Chris Dollin]

Alex Vinokur wrote:

On Nov 16, 11:32 am, Alex Vinokur <[e-mail]>
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

[Mark Bluemel]

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)

[Joe Wright]

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

[pete]

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

[Alex Vinokur]

On Nov 16, 12:25 pm, Richard Heathfield <[e-mail]:

AlexVinokursaid:

On Nov 16, 11:32 am,AlexVinokur<[e-mail]>
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

[Richard Heathfield]

Alex Vinokur said:

On Nov 16, 12:25 pm, Richard Heathfield <[e-mail]:

<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

[James Kuyper]

James Kanze wrote:

On Nov 17, 7:03 pm, pete <[e-mail]:

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

[Alex Vinokur]

On Nov 19, 4:08 pm, James Kanze <[e-mail]:

On Nov 17, 7:03 pm, pete <[e-mail]:

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

[Richard Heathfield]

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

[James Kanze]

On Nov 19, 3:17 pm, James Kuyper <[e-mail]:

James Kanze wrote:

On Nov 17, 7:03 pm, pete <[e-mail]:

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, [phone]