CODEWITHSUNDEEP
c++fstream
R Sahu
R Sahu

Reputation: 206577

Are ios::app mode and fstream::write somehow incompatible with each other?

I am quite puzzled by failure of fstream::write when a file is opened using ios::app mode when there are no such problems when the file is opened using ios::out mode.

Are ios::app mode and fstream::write somehow incompatible with each other?

Sample code:

#include <iostream>
#include <fstream>

void test1()
{
   char const* fname = "out-1.txt";
   std::fstream out;
   out.open(fname, std::ios::app | std::ios::binary);
   if(!out)
   {
      std::cerr << "Cant open file " << fname << " to write to.\n";
      return;
   }

   int val = 10;
   out.write(reinterpret_cast<char*>(&val), sizeof(val));
   if (!out )
   {
      std::cerr << "Error in writing " << val << " to file with ios::app mode.\n";
   }
}

void test2()
{
   char const* fname = "out-2.txt";
   std::fstream out;
   out.open(fname, std::ios::out | std::ios::binary);
   if(!out)
   {
      std::cerr << "Cant open file " << fname << " to write to.\n";
      return;
   }

   int val = 10;
   out.write(reinterpret_cast<char*>(&val), sizeof(val));
   if (!out )
   {
      std::cerr << "Error in writing " << val << " to file with ios::out mode.\n";
   }
}

int main()
{
   test1();
   test2();
   return 0;
}

Output of running the program using g++ 4.8.2:

Error in writing 10 to file with ios::app mode.

Upvotes: 2

Views: 1504

Answers (2)

user657267
user657267

Reputation: 21000

I tried your code and it worked fine on 4.9.2, a quick diff of the tags revealed the following:

diff --git a/libstdc++-v3/include/bits/fstream.tcc b/libstdc++-v3/include/bits/fstream.tcc
index 483a576..21a67cd 100644
--- a/libstdc++-v3/include/bits/fstream.tcc
+++ b/libstdc++-v3/include/bits/fstream.tcc
@@ -1,6 +1,6 @@
 // File based streams -*- C++ -*-

-// Copyright (C) 1997-2013 Free Software Foundation, Inc.
+// Copyright (C) 1997-2014 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -423,7 +423,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
     {
       int_type __ret = traits_type::eof();
       const bool __testeof = traits_type::eq_int_type(__c, __ret);
-      const bool __testout = _M_mode & ios_base::out;
+      const bool __testout = (_M_mode & ios_base::out
+                             || _M_mode & ios_base::app);
       if (__testout)
        {
           if (_M_reading)
@@ -640,7 +641,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
       // Optimization in the always_noconv() case, to be generalized in the
       // future: when __n is sufficiently large we write directly instead of
       // using the buffer.
-      const bool __testout = _M_mode & ios_base::out;
+      const bool __testout = (_M_mode & ios_base::out
+                             || _M_mode & ios_base::app);
       if (__check_facet(_M_codecvt).always_noconv()
           && __testout && !_M_reading)
        {

tl;dr it's a bug, and it's fixed in gcc 4.9

From the commit:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59427

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3945.html#596

Although it's not explicitly mentioned in the standard (as far as I can tell), the linked defect mentions that app should probably imply out.

Upvotes: 3

R Sahu
R Sahu

Reputation: 206577

Thanks to the comment by @user657267, I tried:

out.open(fname, std::ios::out | std::ios::app | std::ios::binary);

and it worked. Strange. I always thought that std::ios::out | std::ios::app would be equal to std::ios::app. That much is indicated in this accepted answer to another SO question.

Upvotes: 0

Related Questions