Adds htonl, htons, ntohl, and ntohs to newlib

Adds htonl, htons, ntohl, and ntohs to newlib

I've implemented the four functions for converting from host to network
byte order and vice-versa. This is necessary because newlib does not
provide them.

I've also added prototypes for these functions to netinet/in.h, and
deleted some macro definitions in arpa/inet.h that Sam pointed out
would cause subtle bugs if users tried to forward declare inet_ntoa()
and inet_ntop().

NOTRY=true
BUG=None
TEST=None
R=noelallen@chromium.org,bradnelson@google.com

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=216706

[bradn, 2013-08-08 01:29:20]

lgtm

[Sam Clegg, 2013-08-08 01:47:25]

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:18: #endif  //
defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
Use C++ comment

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io/syscalls/htons.c (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htons.c:5: #include
"nacl_io/ossocket.h"
Add empty line after includes (here and in other .c files).

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htons.c:18: #endif  //
defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
Use C++ comment

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:272: uint32_t
host_long = 0x44332211;
Doesn't this test depend on the byte order of the host?

Presumably you need some kind of conditional based
on the endianness of the host?

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:275:
memcpy(network_bytes, &network_long, 4);
Just use a cast maybe?

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/third_party/newlib-extras/arpa/inet.h
(right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/third_party/newlib-extras/arpa/inet.h:121:
#define	inet_nsap_ntoa	__inet_nsap_ntoa
Presumably you should remove all these #defines?

They reflect the internal implementation of this stuff
in the newlib/bsd sources which I don't think we want to
mirror.

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/third_party/newlib-extras/netinet/in.h
(right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/third_party/newlib-extras/netinet/in.h:570:
__END_DECLS
Where are these normally defined?  Why can't we just use
the declaration from the BSD headers?

[binji, 2013-08-08 16:07:21]

https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):

https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:14: uint32_t* result =
(uint32_t*) result_bytes;
This breaks strict aliasing rules. Probably will work, but AIUI it is safer to
use a memcpy here (or cast via union, which is technically "unspecified" but
apparently supported by most compilers).

Same for all the other functions.

https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:18: #endif  //
defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
On 2013/08/08 01:47:25, Sam Clegg wrote:
> Use C++ comment

You mean C89 comment.

https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):

https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:272: uint32_t
host_long = 0x44332211;
On 2013/08/08 01:47:25, Sam Clegg wrote:
> Doesn't this test depend on the byte order of the host?
> 
> Presumably you need some kind of conditional based
> on the endianness of the host?

Do we have a big-endian NaCl?

https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:275:
memcpy(network_bytes, &network_long, 4);
On 2013/08/08 01:47:25, Sam Clegg wrote:
> Just use a cast maybe?
> 

I disagree, that breaks strict aliasing. See above.

[Sam Clegg, 2013-08-08 16:45:02]

On 2013/08/08 16:07:21, binji wrote:
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):
> 
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:14: uint32_t* result
=
> (uint32_t*) result_bytes;
> This breaks strict aliasing rules. Probably will work, but AIUI it is safer to
> use a memcpy here (or cast via union, which is technically "unspecified" but
> apparently supported by most compilers).
> 
> Same for all the other functions.
> 
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:18: #endif  //
> defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
> On 2013/08/08 01:47:25, Sam Clegg wrote:
> > Use C++ comment
> 
> You mean C89 comment.
> 
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):
> 
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:272: uint32_t
> host_long = 0x44332211;
> On 2013/08/08 01:47:25, Sam Clegg wrote:
> > Doesn't this test depend on the byte order of the host?
> > 
> > Presumably you need some kind of conditional based
> > on the endianness of the host?
> 
> Do we have a big-endian NaCl?
> 

Maybe not today.  Even so, this at least deserves a comment saying
that that test will break on big endian machines.  Especially since
the whole point of the functions under test is to do different things
depending on the machines endianess.


>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:275:
> memcpy(network_bytes, &network_long, 4);
> On 2013/08/08 01:47:25, Sam Clegg wrote:
> > Just use a cast maybe?
> > 
> 
> I disagree, that breaks strict aliasing. See above.

True true.  Guess I've been writing dangerous C for too long :)  So
we compile with strict aliasing enabled?

[torinmr, 2013-08-08 17:01:21]

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:18: #endif  //
defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
On 2013/08/08 16:07:21, binji wrote:
> On 2013/08/08 01:47:25, Sam Clegg wrote:
> > Use C++ comment
> 
> You mean C89 comment.

Done.

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io/syscalls/htons.c (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htons.c:5: #include
"nacl_io/ossocket.h"
On 2013/08/08 01:47:25, Sam Clegg wrote:
> Add empty line after includes (here and in other .c files).

Done.

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htons.c:18: #endif  //
defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
On 2013/08/08 01:47:25, Sam Clegg wrote:
> Use C++ comment

Done.

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:272: uint32_t
host_long = 0x44332211;
I believe this works on any host byte order: 0x44332211 is the number with 0x44
in the most significant byte, 0x33 in the next most significant byte, etc. This
is true whatever the endianness of the host system. After converting the number
to network byte order, the result should have 0x44 in the first byte, 0x33 in
the second, etc., which is what I'm testing.

On 2013/08/08 01:47:25, Sam Clegg wrote:
> Doesn't this test depend on the byte order of the host?
> 
> Presumably you need some kind of conditional based
> on the endianness of the host?

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:275:
memcpy(network_bytes, &network_long, 4);
I tried that first, but then the compiler complained about dereferencing punned
pointers, so I did this instead.

On 2013/08/08 01:47:25, Sam Clegg wrote:
> Just use a cast maybe?
>

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/third_party/newlib-extras/netinet/in.h
(right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/third_party/newlib-extras/netinet/in.h:570:
__END_DECLS
In BSD (and in Linux, as far as I know), they aren't actually functions, they're
macros that are declared in separate header files for each possible
architecture. Since I took the road of writing actual functions (in an
architecture-independent way), I need to make some declarations. 

On 2013/08/08 01:47:25, Sam Clegg wrote:
> Where are these normally defined?  Why can't we just use
> the declaration from the BSD headers?

[binji, 2013-08-08 17:02:30]

On 2013/08/08 16:45:02, Sam Clegg wrote:
> On 2013/08/08 16:07:21, binji wrote:
> >
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> > File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):
> > 
> >
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> > native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:14: uint32_t*
result
> =
> > (uint32_t*) result_bytes;
> > This breaks strict aliasing rules. Probably will work, but AIUI it is safer
to
> > use a memcpy here (or cast via union, which is technically "unspecified" but
> > apparently supported by most compilers).
> > 
> > Same for all the other functions.
> > 
> >
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> > native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:18: #endif  //
> > defined(PROVIDES_SOCKET_API) && !defined(__GLIBC__)
> > On 2013/08/08 01:47:25, Sam Clegg wrote:
> > > Use C++ comment
> > 
> > You mean C89 comment.
> > 
> >
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> > File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):
> > 
> >
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> > native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:272: uint32_t
> > host_long = 0x44332211;
> > On 2013/08/08 01:47:25, Sam Clegg wrote:
> > > Doesn't this test depend on the byte order of the host?
> > > 
> > > Presumably you need some kind of conditional based
> > > on the endianness of the host?
> > 
> > Do we have a big-endian NaCl?
> > 
> 
> Maybe not today.  Even so, this at least deserves a comment saying
> that that test will break on big endian machines.  Especially since
> the whole point of the functions under test is to do different things
> depending on the machines endianess.

Fair point. 

> 
> 
> >
>
https://codereview.chromium.org/22625004/diff/4001/native_client_sdk/src/libr...
> > native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:275:
> > memcpy(network_bytes, &network_long, 4);
> > On 2013/08/08 01:47:25, Sam Clegg wrote:
> > > Just use a cast maybe?
> > > 
> > 
> > I disagree, that breaks strict aliasing. See above.
> 
> True true.  Guess I've been writing dangerous C for too long :)  So
> we compile with strict aliasing enabled?

It seems that it is automatically enabled when you use -O2 in gcc 4.4. I'm not
certain whether this was changed for later GCC versions though.

[torinmr, 2013-08-08 17:10:07]

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:14: uint32_t* result =
(uint32_t*) result_bytes;
On 2013/08/08 16:07:21, binji wrote:
> This breaks strict aliasing rules. Probably will work, but AIUI it is safer to
> use a memcpy here (or cast via union, which is technically "unspecified" but
> apparently supported by most compilers).
> 
> Same for all the other functions.

Done.

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/third_party/newlib-extras/arpa/inet.h
(right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/third_party/newlib-extras/arpa/inet.h:121:
#define	inet_nsap_ntoa	__inet_nsap_ntoa
I figured I shouldn't remove these for functions that we haven't actually
implemented yet. On the other hand, I guess this leaves a bit of a trap for
anyone who wants to implement one of these functions in the future, so I guess
it makes sense to remove them all now.

On 2013/08/08 01:47:25, Sam Clegg wrote:
> Presumably you should remove all these #defines?
> 
> They reflect the internal implementation of this stuff
> in the newlib/bsd sources which I don't think we want to
> mirror.

[Sam Clegg, 2013-08-08 17:21:39]

lgtm

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:272: uint32_t
host_long = 0x44332211;
On 2013/08/08 17:01:22, torinmr wrote:
> I believe this works on any host byte order: 0x44332211 is the number with
0x44
> in the most significant byte, 0x33 in the next most significant byte, etc.
This
> is true whatever the endianness of the host system. After converting the
number
> to network byte order, the result should have 0x44 in the first byte, 0x33 in
> the second, etc., which is what I'm testing.

Ha!  I stand corrected.  Very good.

> 
> On 2013/08/08 01:47:25, Sam Clegg wrote:
> > Doesn't this test depend on the byte order of the host?
> > 
> > Presumably you need some kind of conditional based
> > on the endianness of the host?
>

https://chromiumcodereview.appspot.com/22625004/diff/4001/native_client_sdk/s...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:275:
memcpy(network_bytes, &network_long, 4);
On 2013/08/08 17:01:22, torinmr wrote:
> I tried that first, but then the compiler complained about dereferencing
punned
> pointers, so I did this instead.

Fair enough.  Ben and the compiler and right I think.
> 
> On 2013/08/08 01:47:25, Sam Clegg wrote:
> > Just use a cast maybe?
> > 
>

[binji, 2013-08-08 17:56:44]

https://codereview.chromium.org/22625004/diff/21001/native_client_sdk/src/lib...
File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):

https://codereview.chromium.org/22625004/diff/21001/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:397: uint16_t
*network_short = reinterpret_cast<uint16_t*>(network_bytes);
same issue here, no?

https://codereview.chromium.org/22625004/diff/21001/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:404: uint32_t
*network_long = reinterpret_cast<uint32_t*>(network_bytes);
and here

[torinmr, 2013-08-08 19:09:38]

https://codereview.chromium.org/22625004/diff/21001/native_client_sdk/src/lib...
File native_client_sdk/src/libraries/nacl_io_test/socket_test.cc (right):

https://codereview.chromium.org/22625004/diff/21001/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:397: uint16_t
*network_short = reinterpret_cast<uint16_t*>(network_bytes);
Darn, you're right!

On 2013/08/08 17:56:44, binji wrote:
> same issue here, no?

https://codereview.chromium.org/22625004/diff/21001/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io_test/socket_test.cc:404: uint32_t
*network_long = reinterpret_cast<uint32_t*>(network_bytes);
On 2013/08/08 17:56:44, binji wrote:
> and here

Done.

[Sam Clegg, 2013-08-08 19:34:44]

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
File native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c (right):

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io/syscalls/htonl.c:16: result_bytes[3] =
(uint8_t) (hostlong & 0xFF);
This code is endian depend thought right?

I'd rather see a correct implementation here that works
on either endianness.

glibc uses "# if __BYTE_ORDER == __BIG_ENDIAN" (would
need to find a working equivalent on win32 if we ever
compile this library on windows again in the future).

Also, I think we can/should avoid the extra function call
here and just do it using bitwise operators.  This is an 
example from naclports (glibc-compat/include/machine/endian.h):

#define __byte_swap_16(x) \
  ( (((x) & 0xff) << 8) | ((unsigned short)(x) >> 8) )

#define __byte_swap_32(x) \
        ( ((x) << 24) | \
         (((x) << 8) & 0x00ff0000) | \
         (((x) >> 8) & 0x0000ff00) | \
         ((x) >> 24) )

(Although it looks like that final left shift needs to be
masked or cast to unsigned!)

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
File native_client_sdk/src/libraries/nacl_io/syscalls/htons.c (right):

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io/syscalls/htons.c:14: result_bytes[1] =
(uint8_t) (hostshort & 0xFF);
Ditto.

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
File native_client_sdk/src/libraries/nacl_io/syscalls/ntohl.c (right):

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io/syscalls/ntohl.c:18: ((uint32_t)
input[3]));
Ditto.

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
File native_client_sdk/src/libraries/nacl_io/syscalls/ntohs.c (right):

https://codereview.chromium.org/22625004/diff/26002/native_client_sdk/src/lib...
native_client_sdk/src/libraries/nacl_io/syscalls/ntohs.c:17: }
Ditto.

[Sam Clegg, 2013-08-08 21:32:54]

OK, after discussing with you I think its fine to have
these trivial routines be less than optimal, at least
initially.

LGTM.

[commit-bot: I haz the power, 2013-08-08 21:46:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torinmr@chromium.org/22625004/26002

[commit-bot: I haz the power, 2013-08-09 00:07:44]

Retried try job too often on linux_chromeos for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-08-09 00:41:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torinmr@chromium.org/22625004/26002

[commit-bot: I haz the power, 2013-08-09 01:56:59]

Retried try job too often on linux_chromeos for step(s) interactive_ui_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-08-09 04:33:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torinmr@chromium.org/22625004/26002

[commit-bot: I haz the power, 2013-08-09 04:34:01]

Failed to apply patch for native_client_sdk/src/build_tools/sdk_files.list:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file native_client_sdk/src/build_tools/sdk_files.list
  Hunk #1 FAILED at 873.
  Hunk #2 succeeded at 889 with fuzz 2 (offset 8 lines).
  1 out of 2 hunks FAILED -- saving rejects to file
native_client_sdk/src/build_tools/sdk_files.list.rej

Patch:       native_client_sdk/src/build_tools/sdk_files.list
Index: native_client_sdk/src/build_tools/sdk_files.list
diff --git a/native_client_sdk/src/build_tools/sdk_files.list
b/native_client_sdk/src/build_tools/sdk_files.list
index
f4e890a9abcb3d6869b99ca94c81692b99769039..aee59c02f7e8a48a18201895c0356e351bc4d4ce
100644
--- a/native_client_sdk/src/build_tools/sdk_files.list
+++ b/native_client_sdk/src/build_tools/sdk_files.list
@@ -873,6 +873,8 @@ src/nacl_io/syscalls/ftruncate.c
 src/nacl_io/syscalls/getcwd.c
 src/nacl_io/syscalls/getdents.c
 src/nacl_io/syscalls/getwd.c
+src/nacl_io/syscalls/htonl.c
+src/nacl_io/syscalls/htons.c
 src/nacl_io/syscalls/inet_ntoa.cc
 src/nacl_io/syscalls/inet_ntop.cc
 src/nacl_io/syscalls/ioctl.c
@@ -881,6 +883,8 @@ src/nacl_io/syscalls/lchown.c
 src/nacl_io/syscalls/link.c
 src/nacl_io/syscalls/mkdir.c
 src/nacl_io/syscalls/mount.c
+src/nacl_io/syscalls/ntohl.c
+src/nacl_io/syscalls/ntohs.c
 src/nacl_io/syscalls/poll.c
 src/nacl_io/syscalls/remove.c
 src/nacl_io/syscalls/rmdir.c

[commit-bot: I haz the power, 2013-08-09 16:29:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/torinmr@chromium.org/22625004/67001

[commit-bot: I haz the power, 2013-08-09 16:31:10]

Change committed as 216706