Four functions:

- StringBytes::StorageSize()
- StringBytes::Size()
- StringBytes::Write()
- StringBytes::Encode()

We don't actually care about header order much, and since we never use
stl classes, 'string' isn't an issue for node ever.

Pretty much everything assumes strings to be utf-8, but crypto
traditionally used binary strings, so we need to keep the default
that way until most users get off of that pattern.

If there is an encoding, and we do 'stream.push(chunk, enc)', and the
encoding argument matches the stated encoding, then we're converting from
a string, to a buffer, and then back to a string.  Of course, this is a
completely pointless bit of work, so it's best to avoid it when we know
that we can do so safely.

Increasing the number of workers from 2 to 8 makes this test
more likely to trigger race conditions. See #5330 for background.

Commit 9352c198 ("child_process: don't emit same handle twice") trades
one bug for another.

Before said commit, a handle was sometimes delivered with messages it
didn't belong to.

The bug fix introduced another bug that needs some explaining. On UNIX
systems, handles are basically file descriptors that are passed around
with the sendmsg() and recvmsg() system calls, using auxiliary data
(SCM_RIGHTS) as the transport.

node.js and libuv depend on the fact that none of the supported systems
ever emit more than one SCM_RIGHTS message from a recvmsg() syscall.
That assumption is something we should probably address someday for the
sake of portability but that's a separate discussion.

So, SCM_RIGHTS messages are never coalesced. SCM_RIGHTS and normal
messages however _are_ coalesced. That is, recvmsg() might return this:

  recvmsg();  // { "message-with-fd", "message", "message" }

The operating system implicitly breaks pending messages along
SCM_RIGHTS boundaries. Most Unices break before such messages but Linux
also breaks _after_ them.  When the sender looks like this:

  sendmsg("message");
  sendmsg("message-with-fd");
  sendmsg("message");

Then on most Unices the receiver sees messages arriving like this:

  recvmsg();  // { "message" }
  recvmsg();  // { "message-with-fd", "message" }

The bug fix in commit 9352c198 assumes this behavior. On Linux however,
those messages can also come in like this:

  recvmsg();  // { "message", "message-with-fd" }
  recvmsg();  // { "message" }

In other words, it's incorrect to assume that the file descriptor is
always attached to the first message. This commit makes node wise up.

Fixes #5330.

client sockets no longer emit 'connect' event inside the
requestListener, update test-net-many-clients to reflect that

Fixes #5255.

This makes Readable.wrap behave properly when the wrapped stream ends
before emitting any data events.

Added a check to see if the stream is in objectMode before deciding
whether to include or exclude data from an old-style wrapped stream.

Preserve default install prefix seen in process.config, but use DESTDIR
for installing to deliniate 32/64 versions, avoid conflicts with PREFIX
settings in config.mk

The stdio and customFds options are never used by exec or execFile,
remove them from the documentation for these functions.

Change vcbuild.bat to ignore VCINSTALLDIR environment variable,
always check for specific VS version and set GYP_MSVS_VERSION
accordingly. Otherwise GYP generates project files in format
that cannot be compiled by VS2012.

When developer calls setBreakpoint with an unknown script name,
we convert the script name into regular expression matching all
paths ending with given name (name can be a relative path too).

To create such breakpoint in V8, we use type `scriptRegEx`
instead of `scriptId` for `setbreakpoint` request.

To restore such breakpoint, we save the original script name
send by the user. We use this original name to set (restore)
breakpoint in the new child process.

This is a back-port of commit 5db936d2 from the master branch.

After much investigation it turns out that the affected servers are
buggy.  user-service.condenastdigital.com:443 in particular seems to
reject large TLS handshake records. Cutting down the number of
advertised ciphers or disabling SNI fixes the issue.

Similarly, passing { secureOptions: constants.SSL_OP_NO_TLSv1_2 }
seems to fix most connection issues with IIS servers.

Having to work around buggy servers is annoying for our users but not
a reason to downgrade OpenSSL. Therefore, revert it.

This reverts commit 4fdb8acd.

1. The stability index must come first, or it messes up the markdown
2. require.extensions is an Object, not an Array.

Close #5387

Several people have reported issues with IIS and Resin servers (or maybe
SSL terminators sitting in front of those servers) that are fixed by
downgrading OpenSSL. The AESNI performance improvements were nice but
stability is more important. Downgrade OpenSSL from 1.0.1e to 1.0.0f.

Fixes #5360 (and others).

Fixes #5379.

Fixed a bug in debugger repl where `restart` command did not work
when a custom debug port was specified via command-line option
--port={number}.

File test/simple/helper-debugger-repl.js was extracted
from test/simple/test-debugger-repl.js

Close #5355

* uv: Upgrade to 0.10.5 (isaacs)

* build: added support for Visual Studio 2012 (Miroslav Bajtoš)

* http: Don't try to destroy nonexistent sockets (isaacs)

* crypto: LazyTransform on properties, not methods (isaacs)

* assert: put info in err.message, not err.name (Ryan Doenges)

* dgram: fix no address bind() (Ben Noordhuis)

* handle_wrap: fix NULL pointer dereference (Ben Noordhuis)

* os: fix unlikely buffer overflow in os.type() (Ben Noordhuis)

* stream: Fix unshift() race conditions (isaacs)

The uname function can return any non-negative int to indicate success.

Strange, but that's how it is documented.  This also fixes a similar
buffer overflow in the even more unlikely event that info.release is
> 255 characters, similar to how 78c5de59 did for info.sysname.

Fixes #3740

In the case of pipelined requests, you can have a situation where
the socket gets destroyed via one req/res object, but then trying
to destroy *another* req/res on the same socket will cause it to
call undefined.destroy(), since it was already removed from that
message.

Add a guard to OutgoingMessage.destroy and IncomingMessage.destroy
to prevent this error.

Allow the IPv4-mapped-as-IPv6 style address.

It needs to apply the Transform class when the _readableState,
_writableState, or _transformState properties are accessed,
otherwise things like setEncoding and on('data') don't work
properly.

Also, the methods wrappers are no longer needed, since they're only
problematic because they access the undefined properties.