[Rd] (PR#7943) documentation enhancement: Note in ?seek for

[ripley@stats.ox.ac.uk]

Actually, there is a known issue: it is often wrong for binary files 
opened in append mode, and we have caught by that too.  So those writers 
did make the sort of error I did not trust them not to make.

On Wed, 15 Jun 2005, Prof Brian Ripley wrote:

> I think the proposed change is appropriate only if the return value is 
> *known* to be reliable for binary files.
>
> I for one do not trust the writers of an OS whom have made such a serious 
> error in one mode (and many other errors elsewhere) not to have made one in 
> closely related code.  Since it is not Open Source, we cannot find out.
>
> On Wed, 15 Jun 2005 tplate at blackmesacapital.com wrote:
>
>> [I started a new bug report for this issue because it was not the
>> primary issue in the original discussion, which was PR#7899]
>> 
>> ligges at statistik.uni-dortmund.de wrote:
>> > Tony Plate wrote:
>> > [snip]
>> >>ligges at statistik.uni-dortmund.de wrote:
>> >>[snip]
>> >>>Note that ?seek currently tells us "The value returned by
>> >>>seek(where=NA) appears to be unreliable on Windows systems, at least
>> >>>for text files."
>> >>>It would be nice if this comment could be removed, of course ....
>> >>
>> >>
>> >>May the explanation could be given that this happens with text files
>> >>because Windows inserts extra characters at end-of-lines when reading
>> >>"text" mode files (but with binary files, things should be fine.) This
>> >>particular issue is documented in Microsoft Windows documentation (e.g.,
>> >>at http://msdn2.microsoft.com/library/75yw9bf3(en-us,vs.80).aspx, found
>> >>by searching on Google using the terms "fseek windows documentation").
>> >>Are there any known issues using seek with binary files under Windows?
>> >>If there are not, then the caveat could be made specific to text files
>> >>and all vagueness removed.
>> >
>> >
>> > Hmm, all I find (including your link) is Windows CE related ...
>> >
>> > Uwe Ligges
>> 
>> For the record, the documentation I pointed to is for Windows 2000 etc,
>> and is not just related to Windows CE (Uwe retracted that claim in a
>> private email).
>> 
>> So, the suggestion to refine the note in ?seek stands.  Perhaps
>> src/library/base/man/seek.Rd could be changed as follows:
>> 
>> OLD:
>> 
>> #ifdef windows
>>   The value returned by \code{seek(where=NA)} appears to be unreliable
>>   on Windows systems, at least for text files.  Clipboard connections
>>   can seek too.
>> #endif
>> 
>> NEW:
>> 
>> #ifdef windows
>>   The value returned by \code{seek()} is unreliable
>>   on Windows systems for text files.  This is because the Windows
>>   file-I/O functions can insert extra characters at end-of-lines
>>   when working with text mode files.  Binary mode files should not
>>   be affected by this issue.  Clipboard connections can seek too.
>> #endif
>> 
>> Of course, if someone knows that the return value of seek() is
>> unreliable on Windows for binary files, this documentation change is
>> innappropriate (and then the documentation should probably be changed
>> from "appears to be unreliable, at least for text files" to "is
>> unreliable, for both binary and text files".
>> 
>> -- Tony Plate
>> 
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 
>
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595