If you receive data from a remote host you might like this. I just used it to find out what data the recv function terminates strings with.
void dump(const unsigned char *data_buffer, const unsigned int length)
{
unsigned char byte;
unsigned int i, j;
for(i=0; i < length; i++)
{
byte = data_buffer;
printf("%02x ", data_buffer); // Display byte in hex.
if(((i%16)==15) || (i==length-1))
{
for(j=0; j < 15-(i%16); j++)
{
printf(" ");
}
printf("| ");
for(j=(i-(i%16)); j <= i; j++)
{ // Display printable byte from line.
byte = data_buffer[j];
if((byte > 31) && (byte < 127)) // Outside printable char range
{
printf("%c", byte);
}
else
{
printf(".");
}
}
printf("\r\n"); // End of the dump line (each line is 16 bytes)
}
}
printf("\r\n");
}
The recv() function doesn't "terminate" anything. It gives you the bytes the other end sent you, in the same order they were sent, absolutely raw. Nothing more -- nothing less. Understanding the organization of the data it gives you means understanding what the other end is sending.
You got \n's because they sent \n's. That's how you define an 'end of line' in text. They might as easily have used NULLs, or had no terminators at all.
Yea I figured that out with dump. Does recv always receive "\r\n" at the end of data or are there special cases where it does not?
The socket doesn't alter the data which goes through it at all. It doesn't even add a terminator for you. It just puts the raw data in the buffer you told it to, and tells you how many bytes you got.
If you were sent a \r\n, you receive an \r\n.
If you weren't sent an \r\n, you don't receive an \r\n.
The data you're dealing is lines of ASCII text from a potentially non-UNIX source, which is why you're getting \r\n. It's part of the data itself.
is it possable to send data to me without a "\r\n" trailer? If so how and how should I handle special cases like that in my loop?
It's entirely possible to send data in absolutely any way you want. It's completely raw. You can cram a .bmp through there as easily as you can a line of text.
How to handle those cases depends entirely on what's being sent.
Since you're writing a text chat-server, it can be pretty expected and demanded that your clients send text. If they don't, they're not playing the same game you are...
Ok so please answer this, if receive is sent data then "\r\n" can be sent without "\r\n" if the sender sees to it, and "\r\n" isn't from gcc ending receives with "\r\n" but "\r\n" is from the actual client sending data. or does my computer receive data and add "\r\n"?
The socket never adds anything extra to the data, at all. Ever.
The client is sending \r\n. You are getting \r\n because the client sends \r\n.
It sends it because that's how ASCII text works -- newlines are used to define when a line ends. Carriage returns are optional, UNIX doesn't need them. If it didn't bother sending \n, how could you possibly tell when a line ends?
That sucks because I rely on rebytes = 3 which is what I thought every program would send. How do you know when you receive one byte and only one byte this way.
You don't. You're relying on things you shouldn't.
Which is an easy fix because your text clients have been sending you terminators all along because of the simple fact that you need them. Just use them already.