Re: opening a non-seekable device file
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?
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.
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.
Uli
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]