8-bit character arrays and strings do not get hit with network byte order issues. Since each individual char in the array is already in order with itself and sequenced with the next char byte in the array... It's the short, ints, and longs that get impacted.
Also, it's not the send and recv calls that do any byte swapping. Byte swapping is related to how the processor lays out integers in memory:
To understand byte order issues, consider the following code on an Intel chip:
// code that demonstrates how integer values are laid out in memory
int msg = 0x01020304;
char* buffer = (char*)&msg;
for (int x = 0; x < 4; x++)
printf("%d %d %d %d\n", buffer[0], buffer[1], buffer[2], buffer[3]);
The result that gets printed out is:
4 3 2 1
What this shows is that x86 processors order the bytes of memory of integers in the opposite order you might expect. The least significant byte or an integer is sequenced first in memory. This is Little Endian.
On a Sparc chip such as old a Sun workstation, that same code prints out:
1 2 3 4
This is Big Endian.
It's only when you write out data to disk or network that the Endianness of the memory sequence matters. As soon as another computer reads the byte sequence written out by another computer, then the CPU reading the integer will interpret it based on it's own endianness.
Endianness typically matters on when writing integers to file or streaming to network. Without a conversion by the application developer, the raw buffer passed to send() gets transmitted exactly as the processor lays the bytes out in memory. See htonl and friends for more details on converting integers and shorts to and from Big Endian (aka Network byte order).