Re: opening a non-seekable device file
Ulrich Eckhardt wrote:
James Kanze wrote:
Ulrich Eckhardt wrote:
How should this code behave?
ofstream out1("/dev/null");
ofstream out2("/dev/null", ios_base::app);
Implementation defined. Both fail under Windows, for example.
Why? I mean, obviously, the path "/dev/null" depends on the OS, and under
the desktop win32 systems the equivalent is "NUL", but is there another
reason?
That's precisely the point. What names are acceptable, and how
they are interpreted, depends on the implementation. A Windows
implementation could accept "/dev/null", and a Unix one could
treate "NUL" specially. And of course, there's no guarantee
that such a "file" even exists. (I was unaware that "NUL"
existed, or was such a file, under Windows, until you told me.
I just supposed that it didn't exist.)
The first says that it should open the file and truncate it, i.e. discard
its content. The second says it should leave the content alone and seek
to the end to append there. Since the device file (or a pipe/socket)
doesn't have any content both truncating and appending make little sense,
but my gut feeling is that at least one of them should succeed, or maybe
even both.
I suspect (without checking) that 1) only Unix and Unix
look-alikes will support this, and 2) both calls will map
directly to calls to Posix open, O_WRONLY | O_CREAT | O_TRUNC in
the first case, and O_WRONLY | O_CREAT | O_APPEND in the second.
With the results of filebuf::open reflecting those of the Posix
open.
I couldn't find any relation between fopen() and open() at opengroup's,
though it is obvious that one must exist. What is indeed true is that
filebuf::open() maps to fopen(), so that is the relevant part.
As I said, "I suspect". Any implementation of fopen (or
filebuf::open) must use open in the end, and the mappings I
suggest above seem the most obvious.
man 2 open says:
| [O_TRUNC] shall have no effect on FIFO special files or terminal
| device files. Its effect on other file types is implementation-defined.
Up to now I'd say that I should be able to expect (strongly) the truncating
variant to work and (not so strongly) the appending one to work, too.
Agreed. (Actually, I'd be surprised if either failed; at the
lower level, O_APPEND is required by Posix to work on all
devices. The rationale for supporting ios_base::app, rather
than just letting the user seek before each write, is to allow
it to be atomic when the implementation supports such; it would
be a very poor Unix implementation that didn't use O_APPEND for
this, and lost the atomicity.)
Formally, I think that the implementation is required to
document such things---implementation defined means documented
behavior. Good luck in finding such documentation, however.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]