2

I'm working on a project where I must send data to server and this client will run on different os's. I knwo the problem with endians on different machines, so I'm converting 'everything' (almost) to network byte order, using htonl and vice-versa on the other end. Also, I know that for a single byte, I don't need to convert anything. But, what should I do for char*? ex:

send(sock,(char*)text,sizeof(text));

What's the best approach to solve this? Should I create an 'intermediate function' do intercept this 'send', then really send char-by-char of this char array? If so, do I need to convert every char to network byte order? I think no, since every char is only one byte. Thinking of this, if I create this 'intermediate functions', I don't have to convert nothing more to network byte order, since this function will send char by char, thus don't need conversion of endians. I any advice on this.

Jonis Maurin Ceará
  • 449
  • 1
  • 4
  • 11
  • 6
    Are you sending text? Then there is no "byte order". A text is a sequence of *single bytes*, you can't have endianness issues with a single byte. Unless you have a wide-character string where each characters is multiple bytes, then you of course could have endianness issues, and need to use a predefined byte-order. – Some programmer dude Mar 31 '17 at 20:09
  • Take a look at these: http://stackoverflow.com/questions/1934168/whats-a-portable-way-of-converting-byte-order-of-strings-in-c http://stackoverflow.com/questions/15877643/is-there-need-to-convert-byte-order-for-strings – Gaurav Pathak Mar 31 '17 at 20:14
  • What Someprogrammerdude said. Endian in text only applies in character encodings that use multi-byte values per character, like UTF-16 or UTF-32 (thus they define UTF-16LE/BE and UTF-32LE/BE variants). Most text encodings use 7/8-bit values, so they do not suffer from endian issues. – Remy Lebeau Mar 31 '17 at 21:27
  • I didn't noticed that, but I'm converting everything into char before sending, even integers. Like this: short p_size = htons(3); end(sock, (char*) &p_size, sizeof (p_size), 0); and my char's is not multi-byte, when used. My questions is: doing this typecastm the 'send' function convert every char of char to a single byte before sending, or it 'understand' as a multi-byte when I call this way? Because if it's the second option, I'll have to make sure that the endian is the same on both ends. – Jonis Maurin Ceará Apr 01 '17 at 02:04
  • How is `text` defined and `initialised`? If it's a pointer how is what is pointing to defined and initialised, if this is still is a pointer how .... – alk Apr 01 '17 at 07:22

1 Answers1

0

I am presuming from your question that the application layer protocol (more specifically everything above level 4) is under your design control. For single byte-wide (octet-wide in networking parlance) data there is no issue with endian ordering and you need do nothing special to accommodate that. Now if the character data is prepended with a length specifier that is, say 2 octets, then the ordering of the bytes must be treated consistently.

Going with network byte ordering (big-endian) will certainly fill the bill, but so would consistently using little-endian. Consistency of byte ordering on each end of a connection is the crucial issue.

If the protocol is not under your design control, then the protocol specification should offer guidance on the issue of byte ordering for multi-byte integers and you should follow that.

Ken Clement
  • 748
  • 4
  • 13