<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 1200: "surprising" char_traits&lt;T&gt;::int_type requirements</title>
<meta property="og:title" content="Issue 1200: &quot;surprising&quot; char_traits&lt;T&gt;::int_type requirements">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue1200.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="1200"><a href="lwg-closed.html#1200">1200</a>. "surprising" <code>char_traits&lt;T&gt;::int_type</code> requirements</h3>
<p><b>Section:</b> 27.2.3 <a href="https://wg21.link/char.traits.typedefs">[char.traits.typedefs]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Sean Hunt <b>Opened:</b> 2009-09-03 <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#char.traits.typedefs">issues</a> in [char.traits.typedefs].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The footnote for <code>int_type</code> in 27.2.3 <a href="https://wg21.link/char.traits.typedefs">[char.traits.typedefs]</a> says that
</p>

<blockquote><p>
If <code>eof()</code> can be held in <code>char_type</code> then some iostreams implementations 
may give surprising results.
</p></blockquote>

<p>
This implies that <code>int_type</code> should be a superset of
<code>char_type</code>. However, the requirements for <code>char16_t</code> and <code>char32_t</code> define
<code>int_type</code> to be equal to <code>int_least16_t</code> and <code>int_least32_t</code> respectively.
<code>int_least16_t</code> is likely to be the same size as <code>char_16_t</code>, which may lead
to surprising behavior, even if <code>eof()</code> is not a valid UTF-16 code unit.
The standard should not prescribe surprising behavior, especially
without saying what it is (it's apparently not undefined, just
surprising). The same applies for 32-bit types.
</p>

<p>
I personally recommend that behavior be undefined if <code>eof()</code> is a member
of <code>char_type</code>, and another type be chosen for <code>int_type</code> (my personal
favorite has always been a <code>struct {bool eof; char_type c;}</code>).
Alternatively, the exact results of such a situation should be defined,
at least so far that I/O could be conducted on these types as long as
the code units remain valid. Note that the argument that no one streams
<code>char16_t</code> or <code>char32_t</code> is not really valid as it would be perfectly
reasonable to use a <code>basic_stringstream</code> in conjunction with UTF character
types.
</p>

<p><i>[
2009-10-28 Ganesh provides two possible resolutions and expresses a preference
for the second:
]</i></p>


<blockquote>
<ol>
<li>
<p>
Replace  [char.traits.specializations.char16_t] para 3 with:
</p>

<blockquote><p>
The member <code>eof()</code> shall return <del>an implementation-defined
constant that cannot appear as a valid UTF-16 code unit</del>
<ins><code>UINT_LEAST16_MAX</code> [<i>Note:</i> this value is guaranteed to
be a permanently reserved UCS-2 code position if <code>UINT_LEAST16_MAX ==
0xFFFF</code> and it's not a UCS-2 code position otherwise &mdash; <i>end
note</i>]</ins>.
</p></blockquote>

<p>
Replace  [char.traits.specializations.char32_t] para 3 with:
</p>

<blockquote><p>
The member <code>eof()</code> shall return <del>an implementation-defined constant that
cannot appear as a Unicode code point</del>
<ins>
<code>UINT_LEAST32_MAX</code> [<i>Note:</i> this value is guaranteed to be a
permanently reserved UCS-4 code position if <code>UINT_LEAST32_MAX ==
0xFFFFFFFF</code> and it's not a UCS-4 code position otherwise &mdash; <i>end
note</i>]</ins>.
</p></blockquote>
</li>
<li>
<p>
In  [char.traits.specializations.char16_t], in the
definition of <code>char_traits&lt;char16_t&gt;</code> replace the definition of nested
typedef <code>int_type</code> with:
</p>

<blockquote><pre>
namespace std {
  template&lt;&gt; struct char_traits&lt;char16_t&gt; {
    typedef char16_t         char_type;
    typedef <del>uint_least16_t</del> <ins>uint_fast16_t</ins> int_type;
     ...
</pre></blockquote>

<p>
Replace  [char.traits.specializations.char16_t] para 3 with:
</p>

<blockquote><p>
The member <code>eof()</code> shall return <del>an implementation-defined
constant that cannot appear as a valid UTF-16 code unit</del>
<ins><code>UINT_FAST16_MAX</code> [<i>Note:</i> this value is guaranteed to
be a permanently reserved UCS-2 code position if <code>UINT_FAST16_MAX ==
0xFFFF</code> and it's not a UCS-2 code position otherwise &mdash; <i>end
note</i>]</ins>.
</p></blockquote>

<p>
In  [char.traits.specializations.char32_t], in the
definition of <code>char_traits&lt;char32_t&gt;</code> replace the definition of nested
typedef <code>int_type</code> with:
</p>

<blockquote><pre>
namespace std {
  template&lt;&gt; struct char_traits&lt;char32_t&gt; {
    typedef char32_t         char_type;
    typedef <del>uint_least32_t</del> <ins>uint_fast32_t</ins> int_type;
     ...
</pre></blockquote>

<p>
Replace  [char.traits.specializations.char32_t] para 3 with:
</p>

<blockquote><p>
The member <code>eof()</code> shall return <del>an implementation-defined constant that
cannot appear as a Unicode code point</del>
<ins>
<code>UINT_FAST32_MAX</code> [<i>Note:</i> this value is guaranteed to be a
permanently reserved UCS-4 code position if <code>UINT_FAST32_MAX ==
0xFFFFFFFF</code> and it's not a UCS-4 code position otherwise &mdash; <i>end
note</i>]</ins>.
</p></blockquote>
</li>
</ol>
</blockquote>


<p><i>[
2010 Rapperswil:
]</i></p>


<blockquote><p>
This seems an overspecification, and it is not clear what problem is being solved - 
these values can be used portably by using the named functions; there is no need 
for the value itself to be portable.

Move to Tentatively NAD.
</p></blockquote>

<p><i>[
Moved to NAD at 2010-11 Batavia
]</i></p>




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





</body>
</html>
