<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 342: seek and eofbit</title>
<meta property="og:title" content="Issue 342: seek and eofbit">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue342.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD">NAD</a> status.</em></p>
<h3 id="342"><a href="lwg-closed.html#342">342</a>. seek and eofbit</h3>
<p><b>Section:</b> 31.7.5.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2001-10-09 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.unformatted">issues</a> in [istream.unformatted].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>I think we have a defect.</p>

<p>According to lwg issue <a href="lwg-defects.html#60" title="What is a formatted input function? (Status: TC1)">60</a><sup><a href="https://cplusplus.github.io/LWG/issue60" title="Latest snapshot">(i)</a></sup> which is now a dr, the
description of seekg in 31.7.5.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> paragraph 38 now looks
like:</p>

<blockquote><p>
Behaves as an unformatted input function (as described in 27.6.1.3, 
paragraph 1), except that it does not count the number of characters 
extracted and does not affect the value returned by subsequent calls to 
gcount(). After constructing a sentry object, if fail() != true, 
executes rdbuf()->pubseekpos( pos).
</p></blockquote>

<p>And according to lwg issue <a href="lwg-defects.html#243" title="get and getline when sentry reports failure (Status: CD1)">243</a><sup><a href="https://cplusplus.github.io/LWG/issue243" title="Latest snapshot">(i)</a></sup> which is also now a dr,
27.6.1.3, paragraph 1 looks like:</p>

<blockquote><p>
Each unformatted input function begins execution by constructing an 
object of class sentry with the default argument noskipws (second) 
argument true. If the sentry object returns true, when converted to a 
value of type bool, the function endeavors to obtain the requested 
input.  Otherwise, if the sentry constructor exits by throwing an 
exception or if the sentry object returns false, when converted to a 
value of type bool, the function returns without attempting to obtain 
any input. In either case the number of extracted characters is set to 
0; unformatted input functions taking a character array of non-zero 
size as an argument shall also store a null character (using charT()) 
in the first location of the array. If an exception is thrown during 
input then ios::badbit is turned on in *this'ss error state. If 
(exception()&amp;badbit)!= 0 then the exception is rethrown. It also counts 
the number of characters extracted. If no exception has been thrown it 
ends by storing the count in a member object and returning the value 
specified. In any event the sentry object is destroyed before leaving 
the unformatted input function.
</p></blockquote>

<p>And finally 27.6.1.1.2/5 says this about sentry:</p>

<blockquote><p>
If, after any preparation is completed, is.good() is true, ok_ != false 
otherwise, ok_ == false.
</p></blockquote>

<p>
So although the seekg paragraph says that the operation proceeds if 
!fail(), the behavior of unformatted functions says the operation 
proceeds only if good().  The two statements are contradictory when only 
eofbit is set.  I don't think the current text is clear which condition 
should be respected.
</p>

<p><b>Further discussion from Redmond:</b></p>

<p>PJP: It doesn't seem quite right to say that <code>seekg</code> is
"unformatted". That makes specific claims about sentry that
aren't quite appropriate for seeking, which has less fragile failure
modes than actual input.  If we do really mean that it's unformatted
input, it should behave the same way as other unformatted input.  On
the other hand, "principle of least surprise" is that seeking from EOF
ought to be OK.</p>

<p>
Pre-Berlin:  Paolo points out several problems with the proposed resolution in
Ready state:
</p>

<ul>
<li>It should apply to both overloads of seekg.</li>
<li>tellg has similar issues, except that it should not call clear().</li>
<li>The point about clear() seems to apply to seekp().</li>
<li>Depending on the outcome of <a href="lwg-defects.html#419" title="istream extractors not setting failbit if eofbit is already set (Status: C++11)">419</a><sup><a href="https://cplusplus.github.io/LWG/issue419" title="Latest snapshot">(i)</a></sup>
if the sentry
sets <code>failbit</code> when it finds <code>eofbit</code> already set, then
you can never seek away from the end of stream.</li>
</ul>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote>
<p>
Moved to NAD. Will reopen if proposed resolution is supplied.
</p>
</blockquote>



<p id="res-342"><b>Proposed resolution:</b></p>

<p>Change 31.7.5.4 <a href="https://wg21.link/istream.unformatted">[istream.unformatted]</a> to:</p>
<blockquote><p>
Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1), except that it does not count the number of characters
extracted, does not affect the value returned by subsequent calls to
gcount(), and does not examine the value returned by the sentry
object. After constructing a sentry object, if <code>fail() !=
true</code>, executes <code>rdbuf()->pubseekpos(pos)</code>.  In
case of success, the function calls clear().
In case of failure, the function calls <code>setstate(failbit)</code>
(which may throw <code>ios_base::failure</code>).
</p></blockquote>

<p><i>[Lillehammer: Matt provided wording.]</i></p>




<p><b>Rationale:</b></p>
<p>In C, fseek does clear EOF.  This is probably what most users would
  expect.  We agree that having eofbit set should not deter a seek,
  and that a successful seek should clear eofbit. Note
  that <code>fail()</code> is true only if <code>failbit</code>
  or <code>badbit</code> is set, so using <code>!fail()</code>, rather
  than <code>good()</code>, satisfies this goal.</p>





</body>
</html>
