recv not completely overwriting last string

[Robert]

Hi,

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

example:

when i first send:

"login robert test"
and then try
"getstatus robert"

i see that it recieved:
"getstatus robertt"

I've noticed this before with some other strings using recv

This is a piece of code i am using:

char buf[256]; /* buffer for client data */

if ((aant_bytes = recv(i, buf, sizeof(buf), 0)) <= 0) {
.....
Do i have to erase the content before the next loop or something?

Thanks in Advance,

Robert

 

[Christopher Benson-Manica]

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

Do i have to erase the content before the next loop or something?

Possibly - what you *do* have to do is ask somewhere where people know about
this. Try comp.unix.programmer.

 

[John]

Hi,

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

example:

when i first send:

"login robert test"
and then try
"getstatus robert"

i see that it recieved:
"getstatus robertt"

I've noticed this before with some other strings using recv

This is a piece of code i am using:

char buf[256]; /* buffer for client data */

if ((aant_bytes = recv(i, buf, sizeof(buf) - 1, 0)) <= 0) {
.....
}
else
{
buf[aant_bytes] = 0;
}

 

[Tom St Denis]

Hi,

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

Um yeah. Just like any other read function it only writes as many bytes as
it reads.

Try memseting your buffer to zero before the read. This also has the
benefit of assuring a NULL byte is present [provided you cap your read to
size -1 bytes].

Tom

 

[nobody]

Hi,

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

Um yeah. Just like any other read function it only writes as many bytes as
it reads.

Try memseting your buffer to zero before the read. This also has the
benefit of assuring a NULL byte is present [provided you cap your read to
size -1 bytes].

Didn't someone say that '\0' (NUL) is not same as NULL? But
seriously, memset()ing (or appending '\0') won't help, generally. Stream
of data may contain embedded '\0's, and receiving end should work
with it as such. As John indicated, in case of success number of "bytes"
received is returned by recv(), which is sufficient information to perform
further processing. All str*() calls on receiving buffer are unusable in
traditional sense, and memsetting (buffer) or terminating (data in the
buffer) will only prevent one case of UB, but won't guarantee correct
results. Using size of data in buf and mem*() functions IMHO will
facilitate better results without overhead of memsetting.
Just hope I wasn't too OT.

 

[xarax]

Hi,

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

Um yeah. Just like any other read function it only writes as many bytes as
it reads.

Try memseting your buffer to zero before the read. This also has the
benefit of assuring a NULL byte is present [provided you cap your read to
size -1 bytes].

Didn't someone say that '\0' (NUL) is not same as NULL? But
seriously, memset()ing (or appending '\0') won't help, generally. Stream
of data may contain embedded '\0's, and receiving end should work
with it as such. As John indicated, in case of success number of "bytes"
received is returned by recv(), which is sufficient information to perform
further processing. All str*() calls on receiving buffer are unusable in
traditional sense, and memsetting (buffer) or terminating (data in the
buffer) will only prevent one case of UB, but won't guarantee correct
results. Using size of data in buf and mem*() functions IMHO will
facilitate better results without overhead of memsetting.
Just hope I wasn't too OT.

Your points are valid. Looking for '\0' is a major
design flaw in such apps that cause the dreaded
"buffer overflaw" exploitation.

Design a packet structure that uses an explicit
packet type number and packet length. Verify the
type and length upon receipt. Character data in
the packet should have a field containing the
actual length of the character data. Try to plan
for the various ways that someone could spoof you
with bad type codes, bad lengths, imbedded null
bytes, etc. Write defensive logic.

 

[Glen Herrmannsfeldt]

Possibly - what you *do* have to do is ask somewhere where people know about
this. Try comp.unix.programmer.

Well, it is pretty much true in C that when a function returns the number of
characters written to a buffer you should use that number. In any case
where '\0' is a legal character the normal string length methods don't work.
This is true on unix, windows, or any other C environment.

-- glen

 

[Michel Bardiaux]

> Hi,
>
> Is it me or is the recv() function not erasing but only overwriting
> the last data it supplied?
>
> example:
>
> when i first send:
>
> "login robert test" and then try "getstatus robert"
>
> i see that it recieved: "getstatus robertt"
>
> I've noticed this before with some other strings using recv
>
> This is a piece of code i am using:
>
> char buf[256]; /* buffer for client data */
>
> if ((aant_bytes = recv(i, buf, sizeof(buf), 0)) <= 0) { ..... Do i
> have to erase the content before the next loop or something?
>
> Thanks in Advance,
>
> Robert
>

You have to clarify the protocol: either the 2 sides exchange
zero-terminated strings, in which case it seems pretty clear that your
server-side is wrong: it sends strlen(msg) characters, thus the recv
does NOT get the zero byte;

or, they exchange arrays of bytes, in which case you have to transmit
the length too (I assume you are not using UDP), and append the zero
byte afterwards on the receiver side.

HtH,

 

[Glen Herrmannsfeldt]

(snip)

You have to clarify the protocol: either the 2 sides exchange
zero-terminated strings, in which case it seems pretty clear that your
server-side is wrong: it sends strlen(msg) characters, thus the recv
does NOT get the zero byte;

or, they exchange arrays of bytes, in which case you have to transmit
the length too (I assume you are not using UDP), and append the zero
byte afterwards on the receiver side.

To get it a little more on topic, the fread() function will have the same
problem.

For TCP one can't depend on the record boundaries being maintained, so null
terminated strings would not be recommended.

-- glen

 

[Keith Thompson]

Hi,

Is it me or is the recv() function not erasing but only overwriting the last
data it supplied?

Um yeah. Just like any other read function it only writes as many bytes as
it reads.

Try memseting your buffer to zero before the read. This also has the
benefit of assuring a NULL byte is present [provided you cap your read to
size -1 bytes].

Zeroing the buffer won't do any good if the incoming data can include
null characters ('\0').