[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows

[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows DMC

Apr 26, 2015

Martin Nowak

Apr 27, 2015

Apr 27, 2015

Apr 28, 2015

Apr 28, 2015

https://issues.dlang.org/show_bug.cgi?id=14505 Vladimir Panteleev <thecybershadow@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thecybershadow@gmail.com --- Comment #4 from Vladimir Panteleev <thecybershadow@gmail.com> --- Is ftell supposed to return specifically the read pointer's position (and not the write pointer's)? --

https://issues.dlang.org/show_bug.cgi?id=14505 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy@yahoo.com --- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> --- I don't think there's any requirement in C for this to be the case. What your test case has exposed is implementation differences for different C libraries. Note that I can write a C program that compiles with both MSVCRT and DMC library, and have the same issue. D does not do anything to the file pointer in the "a+" case. We only do it in the "a" case, since that case will not cause issues for any other usage (you can only write to an "a" file, and it should always write to the end of the file), but fixes an issue with std.process. I'm tempted to close as INVALID. (In reply to Vladimir Panteleev from comment #4) > Is ftell supposed to return specifically the read pointer's position (and > not the write pointer's)? It tells the current position of the file descriptor. There is no different "read" or "write" pointer. When writing, the C library (or the OS in the case of Unixen) seeks the stream to the end. --

https://issues.dlang.org/show_bug.cgi?id=14505 --- Comment #6 from Vladimir Panteleev <thecybershadow@gmail.com> --- (In reply to Steven Schveighoffer from comment #5) > It tells the current position of the file descriptor. There is no different "read" or "write" pointer. When writing, the C library (or the OS in the case of Unixen) seeks the stream to the end. Is that part of the specification? If so, then that contradicts with your above claims and one of the libcs is clearly buggy. --

April 28, 2015

[Issue 14505] File doesn't rewind read pointer for a+ mode on Windows DMC

Posted by Steven Schveighoffer

Permalink

Steven Schveighoffer

Permalink

https://issues.dlang.org/show_bug.cgi?id=14505

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Vladimir Panteleev from comment #6)
> (In reply to Steven Schveighoffer from comment #5)
> > It tells the current position of the file descriptor. There is no different "read" or "write" pointer. When writing, the C library (or the OS in the case of Unixen) seeks the stream to the end.
> 
> Is that part of the specification? If so, then that contradicts with your above claims and one of the libcs is clearly buggy.

That's for "a", and the specification says what happens only on write, not what happens on open (at least clearly). That means it's implementation defined.

Here is a quote from my C 90 spec:

"r" open text file for reading
"w" create text file for writing; discard previous contents if any
"a" append; open or create text file for writing at end of file
"r+" open text file for update (i.e. reading and writing)
"w+" create text file for update; discard previous contents if any
"a+" append; open or create text file for update, writing at end

Update mode permits reading and writing the same file; fflush or a file-positioning function must be called between a read and a write or vice versa.

END QUOTE

It does not specifically say what ftell should return immediately after opening. Only that append writes at the end of the file. Now, one could play lawyer and say that "at end of file" could describe how to open and not how to write, but I think that is not what was intended.

The K&R book I have shows an example of how to implement fopen as an example of how to use unix system interface functions, and shows using lseek to the end of the file on 'a'. It leaves out how to implement the '+' version. This, however, is NOT part of the C specification, it's just an example implementation.

Now, clearly it does say that you have to seek between reads and writes, but it does not say what you have to do on the first read or write. But I think this doesn't apply to the "a" style opens, as those say writing at end of file.

I'm pretty sure the spec is ambiguous enough to allow all the implementations here. I'm going to close as WONTFIX, as technically it's a difference in implementations but I don't think we should fix it in D-land. If someone wants to fix DMC (and Walter's OK with that), then sure. If someone thinks MSVCRT is buggy, good luck with that one :)

--

Forums