| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |\ |
|
| | | |
|
| |\ \
| | |/ |
|
| | | |
|
| |\ \
| | |/
| | |
| | | |
tcltest::test assumes that the cleanup is done first, so moving the cleanup means the the "preserverCore" part needs to move with it.
|
| | |
| | |
| | |
| | | |
tcltest::test assumes that the cleanup is done first, so moving the cleanup means the the "preserverCore" part needs to move with it.
|
| |\ \
| | |/
| | |
| | |
| | | |
until after -output compare.
tcltest -> version 2.3.8
|
| | |\
| | | |
| | | |
| | | |
| | | | |
until after -output compare
tcltest -> version 2.3.8
|
| | | | |
|
| | |/
| | |
| | |
| | | |
until after -output compare
|
| |\ \
| | |/
| | |
| | |
| | | |
schedules cause a ForwardingResult to remain on the forwardList after
it has been processed (IORChan is the origin of the code in IORTrans).
|
| | |
| | |
| | |
| | |
| | | |
schedules cause a ForwardingResult to remain on the forwardList after
it has been processed (IORChan is the origin of the code in IORTrans).
|
| | |
| | |
| | |
| | | |
a ForwardingResult to remain on the forwardList after it has been
processed.
|
| | | |
|
| |\ \
| | |/
| | |
| | | |
kernels that fails to report a writable state on a socket when an error
condition (or remote close) is present.
|
| | |\
| | | |
| | | |
| | | | |
kernels that fails to report a writable state on a socket when an error
condition (or remote close) is present.
|
| | | |\
| | | |/
| | |/| |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
a writable state on a socket when an error condition (or remote close) is
present. Would be good to add actual test suite tests for this, but until
then see demo scripts in the ticket 1758a0b603.
|
| |\ \ \
| | |/ / |
|
| | |/ |
|
| | | |
|
| | | |
|
| |\ \
| | | |
| | | |
| | | | |
semantics close to [lrange] and [lreplace]. [dict merge] is also improved, but is not as strict.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
We do not want parsing an invalid dictionary to give errors about lists!
As compensation, we get greater precision in the errorcode.
|
| | |\ \
| | |/ /
| |/| | |
|
| |\ \ \
| | | |/
| | |/| |
|
| | | | |
|
| |\ \ \
| | |/ /
| | | |
| | | | |
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.
|
| | |\ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |\
| | |_|/
| |/| | |
|
| | | | |
|
| |\ \ \
| | |/ /
| | | |
| | | | |
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?).
|
| | | |
| | | |
| | | |
| | | |
| | | | |
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?).
|
| | |\ \ |
|
| | | | | |
|
| | | | | | |
| | \ \ \ | |
| |\ \ \ \ \
| | | | |/ /
| | | |/| | |
the close of a channel.
|
| | | |\ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| |/ / / /
| | | | |
| | | | | |
a whole raft of test failures. WIP.
|
| | |\ \ \
| | | | | |
| | | | | |
| | | | | | |
connect monitoring. Bug [336441ed59]
|
| | | | | | |
|
| | | |\ \ \
| | | |/ / /
| | |/| | | |
|
| | | | | | |
|
| | | | | |\
| | |_|_|_|/
| |/| | | | |
|