fs-event: fix invalid memory access

file_info->FileName is not null terminated.
2013.12.13, Version 0.10.20 (Stable)

Changes since version 0.10.19:

* linux: fix up SO_REUSEPORT back-port (Ben Noordhuis)

* fs-event: fix invalid memory access (huxingyi)
Now working on v0.10.21
unix: fix a possible memory leak in uv_fs_readdir

Some scandir implementations allocate the dirent struct even if the
directory is empty, so if `scandir` returns 0 there may still be memory
that needs to get deallocated. I have altered uv__fs_readdir to go to
the "deallocation exit area" when 0 files are found in the directory
and continue to return early on a return value of -1.

I went to add a test for this functionality, but it appears that one
already exists (reading an empty directory), so I imagine that the
valgrind builds must only be happening on linux instead of OSX as well?
I have confirmed manually that a program without this fix will
infinitely leak memory, and with this fix the memory usage stays
constant.
2013.12.19, Version 0.10.21 (Stable)

Changes since version 0.10.20:

* unix: fix a possible memory leak in uv_fs_readdir (Alex Crichton)
Now working on v0.10.22
windows: avoid assertion failure when pipe server is closed

When a pipe server is closed, all pending accept requests and their
associated HANDLEs are closed to force windows to cancel the
ConnectNamedPipe IRP. The returned request has the `pipeHandle` field
set to INVALID_HANDLE_VALUE, which trips an assert in
uv_pipe_process_accept_req. This patch fixes that.
code style: strip trailing whitespace
test: add pipe-server-close test

Add a regression test for the pipe server close issue on Windows, which
was reported in joyent/node#6749 and fixed in 7b16a3f.
test: make test-pipe-server-close pass on linux

When a server and a client are both part of the same event loop, and
the client connects to the server, the order in which the connect
callback and the connection callback are called is unspecified.
Apparently on linux the connection callback sometimes happens first,
which is not a bug, and should not make this test fail.
osx: Fix a possible segfault in uv__io_poll

In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.

As concrete evidence, here is the situation that I found caused the
segfault.  The instruction in question along with the relevant register
values was:

    mov    (%r8,%r15,8),%r12

    r8  = 0x7fb0ba800000
    r15 = 0xffffffffffffffff

    r8 + r15 * 8 == 0x7fb0ba7ffff8

It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.
2014.01.08, Version 0.10.22 (Stable)

Changes since version 0.10.21:

* windows: avoid assertion failure when pipe server is closed (Bert
  Belder)
Now working on v0.10.23
linux: relax assumption on /proc/stat parsing

CPU entries in /proc/stat are not guaranteed to be monotonically
increasing, asserting on this assumption can break in cases such
as the UltraSparc II machine shown in #1080.

Signed-off-by: Luca Bruno <lucab@debian.org>
openbsd: fix obvious bug in uv_cpu_info

`int which[]` should not be static here, as the function itself is
changing it

fix joyent/node#6878
process: close stdio after dup2'ing it

Thus allow passing the same file descriptor as the source of multiple
stdios.

Committed with the help and code parts from:

  * Sam Roberts <sam@strongloop.com>

fix #1074
2014.01.23, Version 0.10.23 (Stable)

Changes since version 0.10.22:

* linux: relax assumption on /proc/stat parsing (Luca Bruno)

* openbsd: fix obvious bug in uv_cpu_info (Fedor Indutny)

* process: close stdio after dup2'ing it (Fedor Indutny)
Now working on v0.10.24
linux: move sscanf() out of the assert()

If asserts are turned off then the sscanf() wouldn't have run, being
placed directly in the assert() itself.
linux: fix C99/C++ comment