memcpy() problem

[danu]

Basically I'm trying to do here is put the uint32_t seq_num into the
first 4 bytes of the buf. But every time I do this, it wouldn't get
copied in to the buf at all. Can anyone point out the problem. Thanks a
lot.

char buf[packet_size];
uint32_t seq_num = 0;
uint32_t packet_num = 0;

while((nread = read(fd, buf+8, packet_size-8)) 0) {
packet_num++;
seq_num = htonl(packet_nu m); /* htonl: used to convert the
actual packet_num into network numbers*/
memcpy(buf, &seq_num, 4);
.....
.....
}

[Walter Roberson]

In article <11************ *********@m73g2 000cwd.googlegr oups.com>,
danu <da****@gmail.c omwrote:

>Basically I'm trying to do here is put the uint32_t seq_num into the
first 4 bytes of the buf. But every time I do this, it wouldn't get
copied in to the buf at all. Can anyone point out the problem. Thanks a
lot.

>char buf[packet_size];
uint32_t seq_num = 0;
uint32_t packet_num = 0;

while((nread = read(fd, buf+8, packet_size-8)) 0) {
packet_num++;
seq_num = htonl(packet_nu m); /* htonl: used to convert the
actual packet_num into network numbers*/

htonl() takes as its argument an unsigned long, which might not be
the same size as uint32_t.

memcpy(buf, &seq_num, 4);

uint32_t will be 32 bits if a 32 bit unsigned type exists (and should be
an error otherwise I believe), but a 32 bit unsigned type is not
necessarily 4 bytes long. Suppose for example you are on a DSP in
which char is 32 bits; sizeof(char) is promised to be 1 by the standard,
so on such a system, memcpy() of 4 bytes would be copying 4*32 bits.

>....
....
}

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[danu]

Thanks Walter.
But in my man pages: uint32_t htonl(uint32_t hostlong);

anyways, this shouldn't be the problem. All I want to do is store an
unsigned integer into the first 4 bytes of a char array:

int main () {
char buf[512];
unsigned int temp;
temp = 25115555;

memcpy(buf, &temp, 4) ;

}

shouldn't this memcpy statement suppose to stick that temp value in to
the first 4 bytes of the buf?
anyhelp would be appreciated.
thanks.
Walter Roberson wrote:

In article <11************ *********@m73g2 000cwd.googlegr oups.com>,
danu <da****@gmail.c omwrote:

Basically I'm trying to do here is put the uint32_t seq_num into the
first 4 bytes of the buf. But every time I do this, it wouldn't get
copied in to the buf at all. Can anyone point out the problem. Thanks a
lot.

char buf[packet_size];
uint32_t seq_num = 0;
uint32_t packet_num = 0;

while((nread = read(fd, buf+8, packet_size-8)) 0) {
packet_num++;
seq_num = htonl(packet_nu m); /* htonl: used to convert the
actual packet_num into network numbers*/

htonl() takes as its argument an unsigned long, which might not be
the same size as uint32_t.

memcpy(buf, &seq_num, 4);

uint32_t will be 32 bits if a 32 bit unsigned type exists (and should be
an error otherwise I believe), but a 32 bit unsigned type is not
necessarily 4 bytes long. Suppose for example you are on a DSP in
which char is 32 bits; sizeof(char) is promised to be 1 by the standard,
so on such a system, memcpy() of 4 bytes would be copying 4*32 bits.

....
....
}

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[Walter Roberson]

In article <11************ *********@h48g2 000cwc.googlegr oups.com>,
danu <da****@gmail.c omwrote:

>But in my man pages: uint32_t htonl(uint32_t hostlong);

Hmmm, that isn't what my man page says, but I see it isn't defined
in POSIX.1; uint32_t is what opengroup.org has documented for Unix 97.

>anyways, this shouldn't be the problem. All I want to do is store an
unsigned integer into the first 4 bytes of a char array:

>int main () {
char buf[512];
unsigned int temp;
temp = 25115555;

memcpy(buf, &temp, 4) ;

}

>shouldn't this memcpy statement suppose to stick that temp value in to
the first 4 bytes of the buf?

It does in my test, on a system that happens to use 32 bit int.
On a completely different system that I tried, it was easiest to
modify to unsigned char to get my test output to work:

printf( "%02X.%02X.%02X .%02X\n", buf[0], buf[1], buf[2], buf[3] );

With signed chars, the first version output

../tmp 1002./tht
FFFFFFA3.3B.7F. 01

because of the sign extension as the signed char was converted to
int (by the default argument promotions.)
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Bill Medland]

danu wrote:

Basically I'm trying to do here is put the uint32_t seq_num into the
first 4 bytes of the buf. But every time I do this, it wouldn't get
copied in to the buf at all. Can anyone point out the problem. Thanks a
lot.

char buf[packet_size];
uint32_t seq_num = 0;
uint32_t packet_num = 0;

while((nread = read(fd, buf+8, packet_size-8)) 0) {
packet_num++;
seq_num = htonl(packet_nu m); /* htonl: used to convert the
actual packet_num into network numbers*/
memcpy(buf, &seq_num, 4);
....
....
}

Are you sure? How do you know?
(I presume packet_size is #defined to some number larger than 8)
What's your environment?
(BTW I would probably use sizeof(seq_num) rather than 4).
--
Bill Medland

[J. J. Farrell]

danu wrote:

>
int main () {
char buf[512];
unsigned int temp;
temp = 25115555;

memcpy(buf, &temp, 4) ;

}

shouldn't this memcpy statement suppose to stick that temp value in to
the first 4 bytes of the buf?

If something along these lines doesn't work (assuming sizeof(unsigned
int) is 4) then you have a very broken compiler or environment. How are
you checking whether or not it works?

It needn't work in this particular example since there's no C-defined
way in which you could tell whether or not it had worked. The compiler
could optimize out the memcpy() in this case.

[J. J. Farrell]

Walter Roberson wrote:

In article <11************ *********@h48g2 000cwc.googlegr oups.com>,
danu <da****@gmail.c omwrote:

But in my man pages: uint32_t htonl(uint32_t hostlong);

Hmmm, that isn't what my man page says, but I see it isn't defined
in POSIX.1; uint32_t is what opengroup.org has documented for Unix 97.

<OTIt's defined in the current POSIX standard (2004) as the OP
states. It got there from X/Open. </OT>