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

From: <ripley_at_stats.ox.ac.uk>
Date: Wed 15 Jun 2005 - 19:09:55 GMT


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@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@statistik.uni-dortmund.de wrote:
>> > Tony Plate wrote:
>> > [snip]
>> >>ligges@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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> --
> Brian D. Ripley, ripley@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@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

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Thu Jun 16 05:15:07 2005

This archive was generated by hypermail 2.1.8 : Mon 24 Oct 2005 - 22:27:19 GMT