470,870 Members | 1,396 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,870 developers. It's quick & easy.

Re: Putting an int value in a char array

On May 2, 7:52 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
memcpy(&char_buf, &int_var, sizeof int_var);
[snip]
The shifting method (used on unsigned types) can give you
a portable solution.
Would memcpy and htons & co be a correct approach? My problem is that
it's not only short ints that I have to accomodate, but also the
occasional long; I'd like to have a uniform handling of these
operations.

Also, I'm not sure if the way I found to "deserialize" these values is
safe and recommended:

x = htons(x);
memcpy(&buffer, &x, sizeof x);
/* Later, at the other end: */
x = ntohs(*((unsigned short *) buffer));

I only need unsigned values, so unsigned {short, long} should be
enough. And one final question: would there be any reason to using
uint16_t and uint32_t instead of unsigned short and unsigned long?

Thanks and sorry for the question avalanche,
Vlad
Jun 27 '08 #1
2 3536
Vlad Dogaru <dd****@gmail.comwrites:
On May 2, 7:52 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
> memcpy(&char_buf, &int_var, sizeof int_var);
[snip]
The shifting method (used on unsigned types) can give you
a portable solution.

Would memcpy and htons & co be a correct approach?
First htons and htnol (the "long" version) are POSIX, so technically
off topic here. They are an excellent choice for this problem but
they incur a cost that can be avoided if you are designing a system
for CPUs where the "host" representation is different to the "network"
one. If you can use you own functions, you can avoid this (probably
small) cost by making these operations "null" on your main platform.
My problem is that
it's not only short ints that I have to accomodate, but also the
occasional long; I'd like to have a uniform handling of these
operations.
Then there is htonl and ntohl that take uint32_t values. Note that C
does not insist that long is 32 bits, but uint32_t is.
Also, I'm not sure if the way I found to "deserialize" these values is
safe and recommended:

x = htons(x);
memcpy(&buffer, &x, sizeof x);
That is the safe, portable, way. However, a lot of code will be able
to define the buffer as struct with integer members, so one often
sees:

msg.data1 = htons(x);

or even, the more dangerous:

*(uint16_t *)buffer = htons(x);

The memcpy version avoids any alignment problems and so it more portable.
/* Later, at the other end: */
x = ntohs(*((unsigned short *) buffer));
The reverse would have been

memcpy(&x, &buffer, sizeof x);
x = htons(x);

but the dangerous cast is often used. Data formats in protocols are
often chosen so that there will be no alignment problems on most
common processors, so you will have to decide between portability,
code clarity and speed of packing knowing what you know about the
target systems and the purpose of the code.
I only need unsigned values, so unsigned {short, long} should be
enough. And one final question: would there be any reason to using
uint16_t and uint32_t instead of unsigned short and unsigned long?
Yes. The most important is that POSIX now defines the [nh]to[hn][ls]
functions in terms of these types. These days, you are more likely
to find a system where short 16 bits or long 32 bits than you are
to find one where uint32_t is either not defined or is hard to define
yourself.

--
Ben.
Jun 27 '08 #2
On May 3, 5:01 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
Yes. The most important is that POSIX now defines the [nh]to[hn][ls]
functions in terms of these types. These days, you are more likely
to find a system where short 16 bits or long 32 bits than you are
to find one where uint32_t is either not defined or is hard to define
yourself.
Thank you for all your time, Ben.

Vlad
Jun 27 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by J. Campbell | last post: by
11 posts views Thread by Pontus F | last post: by
2 posts views Thread by Goran | last post: by
20 posts views Thread by Petter Reinholdtsen | last post: by
3 posts views Thread by s.subbarayan | last post: by
2 posts views Thread by Amrit Kohli | last post: by
9 posts views Thread by rob.kirkpatrick | last post: by
9 posts views Thread by Angus | last post: by
8 posts views Thread by Tricky | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.