[Tcl-bugs] [ tcl-Bugs-2176669 ] Strange seek bug

[SourceForge.net <no...@so...>]

Bugs item #2176669, was opened at 2008-10-18 04:57
Message generated for change (Comment added) made by andreas_kupries
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: 8
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: Andreas Kupries (andreas_kupries)
Date: 2009-11-20 11:49

Message:
I have attached 2 scripts, one generating the test input file for the
other.
The other, wr.tcl, should explain why having both input and output
buffered is a bad thing regarding seek and tell, i.e. why they are reported
as error. See the comments in the script.



----------------------------------------------------------------------

Comment By: Andreas Kupries (andreas_kupries)
Date: 2009-11-20 11:03

Message:
Notes ... Regarding "[seek] is documented to flush the output side. "
Yes. That happens too. It happens quite a bit after the check which fails
here.



----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2008-10-20 16:28

Message:
Oops I forgot both to login and to attach the file, sorry ;-)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-10-20 15: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 14: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