summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authordgp <dgp@users.sourceforge.net>2014-08-20 17:50:41 (GMT)
committerdgp <dgp@users.sourceforge.net>2014-08-20 17:50:41 (GMT)
commit8339de0c86602b9b9aeea1efb6245c4e47411884 (patch)
tree2f2ec3691aa2808c3c6f1cf948fc91164c6dec87
parent166fb42c36ba616d9698b30dee6731e6b9edb625 (diff)
downloadtcl-8339de0c86602b9b9aeea1efb6245c4e47411884.zip
tcl-8339de0c86602b9b9aeea1efb6245c4e47411884.tar.gz
tcl-8339de0c86602b9b9aeea1efb6245c4e47411884.tar.bz2
Docs for Tcl_CreateChannelHandler() state that the registered handler procaku_review
will be called back with a mask value. "Mask is an integer mask indicating which of the requested conditions actually exists for the channel; it will contain ***a subset of the bits from the mask argument*** to Tcl_CreateChannelHandler when the handler was created." (emhpasis added). Tcl_NotifyChannel is not honoring this. It passes a mask value that may contain bits not in common with the mask argument to T_CCH(). This commit is a one-liner patch adding in the masking step to make things behave as documented. Thanks to apn for digging this out. (In combination with other questionable code, this led to a hang in test http-4.6 on Windows) Tcl_NotifyChannel() has had this error in all of recorded Tcl history. It's hard to imagine any code dependent on it though. If any exists, it can be revised to pass the mask value it truly needs to T_CCH() and end up with code suitable both before and after this change. If you concur, please merge to core-8-5-branch, and I'll take it from there.
-rw-r--r--generic/tclIO.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/generic/tclIO.c b/generic/tclIO.c
index afffeb8..4452ae9 100644
--- a/generic/tclIO.c
+++ b/generic/tclIO.c
@@ -7716,7 +7716,7 @@ Tcl_NotifyChannel(
if ((chPtr->mask & mask) != 0) {
nh.nextHandlerPtr = chPtr->nextPtr;
- (*(chPtr->proc))(chPtr->clientData, mask);
+ (*(chPtr->proc))(chPtr->clientData, chPtr->mask & mask);
chPtr = nh.nextHandlerPtr;
} else {
chPtr = chPtr->nextPtr;