title: Boost.IOStreams: 'file_descriptor_sink' accepts empty string as pathname; should I guard against that?
body: <p>I develop a library that internally uses Boost.IOStreams.  Recently, I hit an interesting corner case with <a href="http://www.boost.org/doc/libs/1_61_0/libs/iostreams/doc/index.html" rel="nofollow"><code>file_descriptor_sink</code></a>.  It looks like doing</p>
  
  <pre><code>file_descriptor_sink s("");
  </code></pre>
  
  <p>or</p>
  
  <pre><code>file_descriptor_sink s;
  s.open("");
  </code></pre>
  
  <p>is perfectly valid and <code>s.is_open()</code> definitely returns <code>true</code> afterwards.  For me, this is a complete nonsense.  That is to what file is it open?</p>
  
  <p>Two questions in this regard:</p>
  
  <ol>
  <li><p>Is there any function that I could use to detect this condition?  To elaborate, when I first hit this case, I immediately recalled that the following holds:</p>
  
  <pre><code>ofstream ofs("");
  assert(!ofs);
  assert(!ofs.is_open());
  assert(ofs.fail());
  </code></pre>
  
  <p>what is clearly opposite to the <code>file_descriptor_sink</code> behavior in terms of <code>is_open</code> and <code>fail</code> is not even available.  Otherwise, I'd have to directly test for empty string (pathname) before construction of <code>file_descriptor_sink</code> in order to track this condition.</p></li>
  <li><p>Do you agree that throwing well-forged exception to a user of the library in this case would be a good idea?  I was thinking about <a href="http://en.cppreference.com/w/cpp/error/system_error" rel="nofollow"><code>std::system_error</code></a> with the <a href="http://en.cppreference.com/w/cpp/error/errc" rel="nofollow"><code>bad_file_descriptor</code></a> error code.</p></li>
  </ol>