char * can point to any byte?!

[Chad]

On the following sites faq

http://c-faq.com/strangeprob/ptralign.html

"By converting a char * (which can point to any byte) to an int * or
long int *, and then indirecting on it, you can end up asking the
processor to fetch a multibyte value from an unaligned address, which
it isn't willing to do. "

How can char * point to any byte, but int * can't? Can someone clarify
this?

Thanks
Chad

 

[loufoque]

Chad a écrit :

How can char * point to any byte, but int * can't? Can someone clarify
this?

char* is a pointer to a char, which is the size of a byte.
an int may be defined by multiple bytes.

 

[Chad]

Chad a écrit :


char* is a pointer to a char, which is the size of a byte.
an int may be defined by multiple bytes.

So in other words, char * could point to the 2nd or 3rd byte in int?

 

[Keith Thompson]

On the following sites faq

http://c-faq.com/strangeprob/ptralign.html

"By converting a char * (which can point to any byte) to an int * or
long int *, and then indirecting on it, you can end up asking the
processor to fetch a multibyte value from an unaligned address, which
it isn't willing to do. "

How can char * point to any byte, but int * can't? Can someone clarify
this?

For example, on some systems an int is 4 bytes long, and can only be
stored at an address that's a multiple of 4. In that case, an int*
cannot legally point to an odd address.

The details will vary from one system to another. On some systems, an
int* has a different representation than a char*, and an int* isn't
even physically capable of pointing to a single byte.

 

[loufoque]

Chad a écrit :

So in other words, char * could point to the 2nd or 3rd byte in int?

Yes.

 

[Keith Thompson]

So in other words, char * could point to the 2nd or 3rd byte in int?

Yes (assuming an int is at least 3 bytes long).

In fact, any object of any type can be treated as an array of unsigned
char.

 

[slebetman]

So in other words, char * could point to the 2nd or 3rd byte in int?

Correct (well.. some systems have 2 byte ints..).

On some systems like x86 this is not a problem since memory is byte
aligned. But on other systems like ARM (iPaq, Palm, Smartphone etc)
this is a problem because memory access is word aligned (in the case of
ARM it is 32bit aligned). So the compiler will need to generate special
instructions like shifts to access bytes in the word.

Using char* tells the compiler that you want byte access to memory.
Using int* the compiler may not be able to access unaligned ints in
memory. This is the memory alignment 'bug' that people refer to when
porting badly written Linux programs to the ARM CPU.

 

[Grumble]

Correct (well... some systems have 2 byte ints).

Some even have 1-byte ints.

 

[Charles Krug]

On the following sites faq

http://c-faq.com/strangeprob/ptralign.html

"By converting a char * (which can point to any byte) to an int * or
long int *, and then indirecting on it, you can end up asking the
processor to fetch a multibyte value from an unaligned address, which
it isn't willing to do. "

How can char * point to any byte, but int * can't? Can someone clarify
this?

Hmmmm . . .

Because char * is a pointer to char, and int * is a pointer to int?

It's a surprisingly difficult question because it winds up being
different on every platform.

There are a great many platforms--including ones found in many homes and
schools--where you can blithly point a char * at most anything at all
and it Just Works the way one might wish.

Then you get a job programming a device that only has 32-bit data types
but it has to communicate with an 8-bit device that's not mapped to a
32-bit boundary.

It boils down to a question of the device you're programming and how it
deals with unaligned memory access. The best source of information is
going to be your chip vendor's documentation.

If you'd like an example, take a look at the C Language Reference
manuals for two TI families of DSP's. The "All 32-bits all the time"
TMS320c4x versus the "Oh this is almost like a PC" TMC320c67.

I'm afraid beyond the FAQ it gets implementation-specific rather
quickly.

 

[slebetman]

Some even have 1-byte ints.

They may have 1 byte words, which is what 8 bit systems have, but here
in c.l.c they cannot have 1 byte ints. By definition, ints are at least
16 bits.

Oh wait, I forgot... systems can have 16 bit bytes as well... so you
are right ;-)

 

[Jordan Abel]

They may have 1 byte words, which is what 8 bit systems have, but here
in c.l.c they cannot have 1 byte ints. By definition, ints are at least
16 bits.

Oh wait, I forgot... systems can have 16 bit bytes as well... so you
are right ;-)

Plus, you have to make a judgement call over how non-conforming an
implementation can be before it's "not C". I've heard rumors of "C"
implementations for embedded systems that had 8-bit ints, or 16-bit ints
but no longs. There's also the question of "primordial" implementations,
that is, those that are prior to K&R1, or contemporary with it but
substantially different. It's hard to argue that the dialect described
in http://www.lysator.liu.se/c/bwk-tutor.html isn't C.