Bug 14505 – File doesn't rewind read pointer for a+ mode on Windows DMC

cat > bug.d << CODE void main() { import std.file, std.stdio; std.file.write("test.txt", "content"); auto f = File("test.txt", "a+"); assert(f.tell == 0); } CODE dmd -run bug ---- Happens for DMC's and MSVC's runtime.

Related to bug 14422.

(In reply to Martin Nowak from comment #1) > Related to bug 14422. Issue 14422

Correction, this is only a DMC problem, works fine with MSVC.

Is ftell supposed to return specifically the read pointer's position (and not the write pointer's)?

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.

(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.

(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 :)