memcpy() and endianness

[Case]

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/
}

/* Thanks for listening! Case */

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Case wrote:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);
First off, sizeof(i) may not be equal to 4. So, this may or may not do what you
expect it to do.

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/ Nothing can be said about the value of i.
1) you may or may not have set the value of i to a known quantity. If sizeof(i)
is greater than 4, then you didn't set i's storage completely, and if sizeof(i)
is less than 4, then some of your initialization was not used to set i (and
overwrote something else instead)
2) the standard doesn't specify how an integer is to map into a character array.
It doesn't specify a particular endianness for integers.

}

/* Thanks for listening! Case */

- --
Lew Pitcher
IT Consultant, Enterprise Application Architecture,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAn5YjagV FX4UWr64RAgNYAK CGonjwOnfElYsZr CbrxpSzMS+rdgCg 0oeE
3mzpLbH2n9S6Pv2 gfAIfvTs=
=hmVd
-----END PGP SIGNATURE-----

[Martin Dickopp]

Case <[e-mail]> writes:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/
}

/* Thanks for listening! Case */

A signed integer has a sign bit, a number of value bits (each of which
has a value that is an integral power of two), and possibly padding
bits. The standard does not impose any rule how the bits have to be
arranged.

For example, in the special case of `int' having 31 value bits and no
padding bits, there are 263130836933693 530167218012160 000000 (== 32!)
possibilities how to arrange the bits. Three are particularly popular
among implementors, so that they have special names: little, big, and
mixed endian. The remaining 263130836933693 530167218012159 999997 don't
have any endianess.

Therefore, not much can be said about the value of `i' from the
perspective of the C standard.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Case]

Lew Pitcher wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Case wrote:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

First off, sizeof(i) may not be equal to 4. So, this may or may not do what you
expect it to do.

Yes, I know. That's why I said i is '4-byte == 4-char'.

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/
Nothing can be said about the value of i.
1) you may or may not have set the value of i to a known quantity. If sizeof(i)
is greater than 4, then you didn't set i's storage completely, and if sizeof(i)
is less than 4, then some of your initialization was not used to set i (and
overwrote something else instead)

It's 4 as I said (see above). And, doesn't the C standard say that
'global' data (as i is) is initialized to 0?!
2) the standard doesn't specify how an integer is to map into a character array.
It doesn't specify a particular endianness for integers.

[Case]

Martin Dickopp wrote:

Case <[e-mail]> writes:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/
}

/* Thanks for listening! Case */

A signed integer has a sign bit, a number of value bits (each of which
has a value that is an integral power of two), and possibly padding
bits. The standard does not impose any rule how the bits have to be
arranged.

For example, in the special case of `int' having 31 value bits and no
padding bits, there are 263130836933693 530167218012160 000000 (== 32!)
possibilities how to arrange the bits. Three are particularly popular
among implementors, so that they have special names: little, big, and
mixed endian. The remaining 263130836933693 530167218012159 999997 don't
have any endianess.

Therefore, not much can be said about the value of `i' from the
perspective of the C standard.

How many different values can i have given code above? With value I
mean a number at C level, not implementation level.

[Case]

Lew Pitcher wrote:

Case wrote:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

First off, sizeof(i) may not be equal to 4. So, this may or may not do what you
expect it to do.

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/

Nothing can be said about the value of i.
1) you may or may not have set the value of i to a known quantity. If sizeof(i)
is greater than 4, then you didn't set i's storage completely, and if sizeof(i)
is less than 4, then some of your initialization was not used to set i (and
overwrote something else instead)
2) the standard doesn't specify how an integer is to map into a character array.
It doesn't specify a particular endianness for integers.

In terms of implementation, what mappings mapping are common?

[CBFalconer]

Case wrote:

Lew Pitcher wrote:

Case wrote:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

First off, sizeof(i) may not be equal to 4. So, this may or may
not do what you expect it to do.

Yes, I know. That's why I said i is '4-byte == 4-char'.

.... snip ...

Nothing can be said about the value of i.
1) you may or may not have set the value of i to a known
quantity. If sizeof(i) is greater than 4, then you didn't set
i's storage completely, and if sizeof(i) is less than 4, then
some of your initialization was not used to set i (and
overwrote something else instead)

It's 4 as I said (see above). And, doesn't the C standard say
that 'global' data (as i is) is initialized to 0?!

The fact that 'you said' doesn't make it so. The initialization
doesn't matter, because you have no idea what bits or bytes belong
where. This newsgroup deals only with portable standard C, so
your particular platform is of no interest whatsoever.

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush.
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.

[Eric Sosman]

Case wrote:

[code setting the bytes of a four-byte `int' to:]
char data[] = { 0x78, 0x56, 0x34, 0x12 };

In terms of implementation, what mappings mapping are common?

"Big-Endian:" the value is 0x78563412

"Little-Endian:" the value is 0x12345678

"Middle-Endian:" the value is 0x56781234

Other formats are possible, of course, and permitted by the
C Standard. Also, the latest C99 Standard permits an `int' to
have "trap representations " somewhat like an IEEE signalling NaN:
some arrangements of bits may signify "erroneous data" rather than
encoding a numeric value. It's at least possible thet storing
these four bytes in an integer could produce such a result.

For what it's worth, I've never encountered a machine that
used trap representations in integers or that used an "endian"
arrangement other than the three listed above. YMMV.

--
Er*********@sun .com

[Martin Dickopp]

Case <[e-mail]> writes:

Martin Dickopp wrote:

Case <[e-mail]> writes:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/
}

/* Thanks for listening! Case */ A signed integer has a sign bit, a number of value bits (each of which
has a value that is an integral power of two), and possibly padding
bits. The standard does not impose any rule how the bits have to be
arranged.
For example, in the special case of `int' having 31 value bits and no
padding bits, there are 263130836933693 530167218012160 000000 (== 32!)
possibilities how to arrange the bits. Three are particularly popular
among implementors, so that they have special names: little, big, and
mixed endian. The remaining 263130836933693 530167218012159 999997 don't
have any endianess.
Therefore, not much can be said about the value of `i' from the
perspective of the C standard.

How many different values can i have given code above?

If type `int' has 31 value bits and no padding bits, and bytes have 8
bits, then `i' will have 13 one-bits and 19 zero-bits. The number of
values with this property is given by the binomial coefficient
"32 choose 13", which is 347373600. That's how many different values
`i' can have.
With value I mean a number at C level, not implementation level.

I don't know what you mean by "C level" or "implementa tion level".

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Christian Bau]

In article <40************ *********@news. xs4all.nl>, Case <[e-mail]>
wrote:

#include <string.h>

int i; /* 4-byte == 4-char */
char data[] = { 0x78, 0x56, 0x34, 0x12 };

int main()
{
memcpy(&i, data, 4);

/*
* Thinking about endianness, what can be said about
* the value of i according to the C-spec?
*/
}

Nothing.