commit b721761a1ac6504321f5f7c058d4320e783a8cf8
author Mirko Bonadei <mbonadei@webrtc.org> Thu Mar 28 16:10:29 2019
committer Commit Bot <commit-bot@chromium.org> Sun Mar 31 11:55:09 2019
tree 51fae8f9b119d25ec66888d04308de1747d8537c
parent 0c7a9cae28edcd574177abd40f81c57857e284e3

Reworking byte order utility functions for Windows platforms.

Functions htonll and ntohll are only available when
NTDDI_VERSION>=NTDDI_WIN8 or INCL_EXTRA_HTON_FUNCTIONS is defined,
instead of assuming this to be true, this CL replaces them with
_byteswap_uint64 [1].

On top of that, the following functions were assuming host to be
little endian on Windows and NaCl:
- htobe16(v)
- htobe32(v)
- be16toh(v)
- be32toh(v)
- htobe64(v)
- be64toh(v)

But it is the application's responsibility to check the host
endianness before calling ntohs, ntohl (and probably also htons and
htonl). See [2], especially: "The ntohs function returns the value
in host byte order. If the netshort parameter is already in host byte
order, then this function will reverse it. It is up to the application
to determine if the byte order must be reversed.".

After this CL, WebRTC should do the right thing based on the value
of WEBRTC_ARCH_{BIG,LITTLE}_ENDIAN.

[1] - https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/byteswap-uint64-byteswap-ulong-byteswap-ushort
[2] - https://docs.microsoft.com/en-us/windows/desktop/api/winsock/nf-winsock-ntohs

Bug: None
Change-Id: I61ca882ad81dd090fd164b0fdfeec64cd088a71d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/129901
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Noah Richards <noahric@chromium.org>
Reviewed-by: Yves Gerey <yvesg@google.com>
Reviewed-by: Yves Gerey <yvesg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27371}