Is opening the SAME file in two different fstreams Undefined Behaviour?

Question

This recently asked question has raised another interesting issue, as discussed in the comments to one of its answers.

To summarize: the OP there was having issues with code like that below, when subsequently attempting to read and write data from/to the two streams 'concurrently':

ifstream infile;
infile.open("accounts.txt");

ofstream outfile;
outfile.open("accounts.txt");

Although the issue, in itself, was successfully resolved, it has raised a question to which I cannot find an authoritative answer (and I've made some quite extensive searches of Stack Overflow and the wider web).

It is very clearly stated what happens when calling the open() method of a stream that is already associated with a file (cppreference), but what I cannot find an answer to is what happens when (as in this case) the file is already associated with a (different) stream.

If the stream is already associated with a file (i.e., it is already open), calling this function fails.

I can see several possible scenarios here:

1. The second open call will fail and any attempted writes to it will also fail (but that is not the case in the cited question).
2. The second open call will 'override' the first, effectively closing it (this could explain the issues encountered in said code).
3. Both streams remain open but enter into a 'mutual clobbering' match regarding their internal file pointers and buffers.
4. We enter the realm of undefined (or implementation-defined) behaviour.

Note that, as the first open() call is made by an input stream, the operating system will not necessarily 'lock' the file, as it probably would for an output stream.

So, does anyone have a definitive answer to this? Or a citation from the Standard (cppreference will be 'acceptable' if nothing more authoritative can be found)?

Answer 1

basic_filebuf::open (and all things that depend on it, like fstream::open) has no statement about what will happen in this case. A filesystem may allow it or it may not.

What the standard says is that, if the file successfully opens, then you can play with it in accord with the interface. And if it doesn't successfully open, then there will be an error. That is, the standard allows a filesystem to permit it or forbid it, but it doesn't say which must happen. The implementation can even randomly forbid it. Or forbid you from opening any files in any way. All are (theoretically) valid.