From: SourceForge.net <no...@so...> - 2008-10-20 23:28:44
|
Bugs item #2176669, was opened at 2008-10-18 13:57 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2176669&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 25. Channel System Group: current: 8.4.19 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: Strange seek bug Initial Comment: I've got strange seek behavior executing this simple script (Windows XP, tcl 8.4.19/8.5.2/8.6a1): --- exp.tcl --- set fd [open hash.db r+] seek $fd 100 puts [tell $fd] puts -nonewline $fd 0 puts [tell $fd] read $fd 2 seek $fd 0 puts [tell $fd] --- Result is: 100 101 error during seek on "filea3bf40": bad address in system call argument while executing "seek $fd 0" (file "exp.tcl" line 8) ------------ It seems that it originates from here: ----- tclIO.c ----- ... In Tcl_Seek: /* * Compute how much input and output is buffered. If both input and output * is buffered, cannot compute the current position. */ inputBuffered = Tcl_InputBuffered(chan); outputBuffered = Tcl_OutputBuffered(chan); if ((inputBuffered != 0) && (outputBuffered != 0)) { Tcl_SetErrno(EFAULT); return Tcl_LongAsWide(-1); } -------- So, [flush]-ing channel before seeking helps. I didn't find this documented anywhere. Moreover, as Alexandre Ferrieux said, [seek] is documented to flush the output side. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2008-10-21 01:28 Message: Oops I forgot both to login and to attach the file, sorry ;-) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-10-21 00:37 Message: The attached patch fixes that strange behavior *and* passes the test suite. The idea is that the check was useless because of the DiscardInputQueued(). The important part which I kept is the if (mode == SEEK_CUR) { offset -= inputBuffered; } What is unclear to me though, is the reason for this check... ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2008-10-19 23:54 Message: Looking at the code in Tcl_Seek, there's something I don't understand: a few lines below the above test against simultaneous input and output data buffered, there is: DiscardInputQueued(statePtr, 0); whose effect is to guaranteed nothing's left in the input buffer chain. So, why not do it first, and avoid the error ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2176669&group_id=10894 |