<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE TIP SYSTEM "http://tcl.activestate.com/cgi-bin/tct/tip/tipxml.dtd">
<!-- Converted at Thu Feb 09 12:15:00 GMT 2012 -->
<!-- TIP AutoGenerator - written by Donal K. Fellows -->

<TIP number='91'>
<header><title>Backward Compatibility for Channel Types with 32-bit SeekProcs</title><author address="mailto:fellowsd@cs.man.ac.uk">Donal K. Fellows</author><status type='project' state='final' tclversion="8.4" vote='after'>$Revision: 1.5 $</status><history></history><created day='3' month='may' year='2002' /></header>
<abstract><tipref type="text" tip="72"/> broke backward-compatibility for channels that supported the [seek] command, and this TIP adds the ability for old-style channels to work with the underlying 64-bit architecture.</abstract>
<body><section title="Rationale">
<para>Although the ability to work with large files (as added by <tipref type="text" tip="72"/>) is crucially useful in many situations, it has introduced a few problems, one of which being that it broke backward compatibility for channel types (see <url ref="http://sourceforge.net/tracker/?func=detail&amp;atid=410295&amp;aid=551677&amp;group_id=34191"/> for details.) Following discussion with the people concerned, I believe it is possible to modify the channel type structure so that old-style channels - i.e. those compiled against Tcl 8.3 - can still be supported (though with a limited range of operation.)</para>
</section>
<section title="Proposed Change">
<para>The <emph style="italic">Tcl_ChannelType</emph> structure will have an extra field appended of type <emph style="italic">Tcl_DriverWideSeekProc</emph> called <emph style="italic">wideSeekProc</emph>, which shall be guaranteed to be present (though possibly NULL) whenever the version of the <emph style="italic">Tcl_ChannelType</emph> structure is at least <emph style="italic">TCL_CHANNEL_VERSION_3</emph>. The type <emph style="italic">Tcl_DriverSeekProc</emph> shall be reverted to its pre-<tipref type="text" tip="72"/> version, with the current type of <emph style="italic">Tcl_DriverSeekProc</emph> being transferred to the type <emph style="italic">Tcl_DriverWideSeekProc</emph>. In order to facilitate stacked channels, an additional requirement shall be imposed that if a channel driver implements a <emph style="italic">wideSeekProc</emph>, then it shall also implement a <emph style="italic">seekProc</emph>, so allowing stacked channels to work entirely in one domain or the other (well, in simple cases at least.)</para>
<para>Semantically, the core will handle seeks by preferring to use a <emph style="italic">wideSeekProc</emph> if present, and using the <emph style="italic">seekProc</emph> otherwise. Considering just the case where the <emph style="italic">seekProc</emph> is used, if the offset argument exceeds that which is representable in a <emph style="italic">long</emph>, <emph style="italic">Tcl_Seek</emph> will fail, simulating a system error of EOVERFLOW.</para>
<para>The only Tcl core channel which will need modification is the <emph style="italic">file</emph> channel; this will be adapted to generate an error of EOVERFLOW when the resulting offset in a file would otherwise exceed that which can be expressed in a <emph style="italic">long</emph> (which has the downside of making the seek operation no longer atomic when using the old interface, since the file offset will need to be restored to its old position in such cases.) On 64-bit platforms, both <emph style="italic">seekProc</emph> and <emph style="italic">wideSeekProc</emph> will be the same function.</para>
</section>
<section title="Rejected Alternatives">
<para>I considered overloading the <emph style="italic">seekProc</emph> field to have different types depending on the value of the <emph style="italic">version</emph> field, but that&apos;s remarkably ugly and forces people to adapt rapidly at a source level. I don&apos;t know about everyone else, but I don&apos;t use a lot of programs at the moment that actually need access to files larger than 2GB.</para>
<para>I also considered allowing code to only implement the <emph style="italic">wideSeekProc</emph> but it was easier to code the way I ended up doing it and I don&apos;t think there are that many people writing channel drivers that support seeking anway.</para>
</section>
<section title="Copyright">
<para>This document has been placed in the public domain.</para>
</section>
</body></TIP>

