merge core-8-5-branch
Try not to loose FD_CONNECT by switching monitoring off.
win socket -async: do not loose connect notification by temporarily stop connect monitoring. Bug [336441ed59]
Correct the interest masks in the Tcl_CreateFileHandler() calls in
PipeWatchProc().  When we are interested in both readable and writable
events of a command pipeline channel, we only want the readable from
the read end of the pipe, and the writable from the write end of the pipe.
Correct the interest masks in the Tcl_CreateFileHandler() calls in PipeWatchProc(). When we are interested in both readable and writable events of a command pipeline channel, we only want the readable from the read end of the pipe, and the writable from the write end of the pipe.
Improve robustness of the socket tests against systems that support IPv6, but don't resolve localhost to ::1 (and vice versa for IPv4 and 127.0.0.1).
These edits make the tests socket-14.11.[01] stop hanging, but also introduce
a whole raft of test failures.  WIP.
These edits make all tests outside of socket-14.* pass on OSX Mavericks.
Several socket-14.* tests failing there, and those that pass are very slow
about it.  Firewall or poor networking configuration may be playing a role.
[1b0266d8bb] Working towards ensuring that all dict operations are sufficiently strict.
merge trunk
Backport I/O core fixes made known by async socket work on trunk.
[734138ded8] Revisions so that unreported errors don't get lost during
the close of a channel.
merge fork of 8.5 branch
Valgrind doesn't like use of uninitialized variables.
more tests, cleaning up the code a bit
Revise DiscardOutput() to account for revisions to the loop in FlushChannel()
which is its only caller.  We need to discard the curOutPtr buffer as well,
and not count on another pass through the loop to attempt to flush it
(and raise the same failure again?).
Revise DiscardOutput() to account for revisions to the loop in FlushChannel() which is its only caller. We need to discard the curOutPtr buffer as well, and not count on another pass through the loop to attempt to flush it (and raise the same failure again?).
Add missing calls to Tcl_DecrRefCount() in string object man page examples.
Fixed a tricky interaction of IO system and encodings which could
result in a panic.

The relevant function is ReadChars() (short RC in the following).

When the encoding and translation transforms deliver more characters
than were requested the iterative algorithm used by RC reduces the
value of "dstLimit" (= the number of bytes allowed to be copied into
the destination buffer) to force the next round to deliver less
characters, hopefully the number requested.

The existing code used the byte located just after the last wanted
character to determine the new limit. The resulting value could
_undershoot_ the best possible limit because Tcl_ExternalToUtf would
effectively reduce this limit further, by TCL_UTF_MAX+1, to have
enough space for a single multi-byte character in the buffer, and a
closing '\0' as well.

One effect of this were additional calls to ReadChars() to retrieve
the characters missed by a call with an undershot limit.

In the limit (sic) however this was also able to cause a full-blown
"Buffer Underflow" panic if the original request was for less than
TCL_UTF_MAX characters (*), and we are using a single-byte encoding
like iso-8859-1. Because then the undershot dstLimit would prevent the
next round from copying anything, and causing it to try and
consolidate the current buffer with the next buffer, thinking that it
had to merge a multi-byte character split across buffer boundaries.

(Ad *) For example because the previous call had undershot already and
left only such a small amount of characters behind!

The basic fix to the problem is to add TCL_UTF_MAX back to the limit,
like is done in all the (three) other places in RC setting a new
one. Note however that this naive fix may generate a new limit which
is the same as the old, or possibly larger. If that happens we act
very conservatively and reduce the limit by only one byte instead.

While I believe that this last conservative approach will never reduce
the limit to TCL_UTF_MAX or less before reaching a state where it
returnds the exact amount of requested characters I still added a
check against this situation anyway, causing a new panic if triggered.
When too many chars are read by ReadChars() and we trim the limits to
get it right on the next pass, don't forget the TCL_UTF_MAX padding
demanded by Tcl_ExternalToUtf().  (Thanks for finding that, aku!)
Fix the factorPtr management.  It was just totaly wrong. The factor should
be a ratio of the record of bytes read to the record of chars read.
With those fixes, new test io-12.6 covers the "too many chars" code.