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.

 

[Chris Dollin]

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?

 

[Alex Vinokur]

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:

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.

 

[Chris Dollin]

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

 

[Mark Bluemel]

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]

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.

 

[pete]

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.

 

[Alex Vinokur]

AlexVinokursaid:

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:

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.

 

[James Kanze]

Joe Wright 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 Kuyper]

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]

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

 

[Richard Heathfield]

Alex Vinokur said:

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

All of them are unsafe.

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

 

[James Kanze]

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.