<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 143: C .h header wording unclear</title>
<meta property="og:title" content="Issue 143: C .h header wording unclear">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue143.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="143"><a href="lwg-closed.html#143">143</a>. C .h header wording unclear</h3>
<p><b>Section:</b> 17.15 <a href="https://wg21.link/support.c.headers">[support.c.headers]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Christophe de Dinechin <b>Opened:</b> 1999-05-04 <b>Last modified:</b> 2023-02-07</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#support.c.headers">issues</a> in [support.c.headers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>[depr.c.headers] paragraph 2 reads:</p>

<blockquote>

<p>Each C header, whose name has the form name.h, behaves as if each
name placed in the Standard library namespace by the corresponding
cname header is also placed within the namespace scope of the
namespace std and is followed by an explicit using-declaration
(_namespace.udecl_)</p>

</blockquote>

<p>I think it should mention the global name space somewhere...&nbsp;
Currently, it indicates that name placed in std is also placed in
std...</p>

<p>I don't know what is the correct wording. For instance, if struct
tm is defined in time.h, ctime declares std::tm. However, the current
wording seems ambiguous regarding which of the following would occur
for use of both ctime and time.h:</p>

<blockquote>
  <pre>// version 1:
namespace std {
        struct tm { ... };
}
using std::tm;

// version 2:
struct tm { ... };
namespace std {
        using ::tm;
}

// version 3:
struct tm { ... };
namespace std {
        struct tm { ... };
}</pre>
</blockquote>

<p>I think version 1 is intended.</p>

<p><i>[Kona: The LWG agreed that the wording is not clear. It also
agreed that version 1 is intended, version 2 is not equivalent to
version 1, and version 3 is clearly not intended. The example below
was constructed by Nathan Myers to illustrate why version 2 is not
equivalent to version 1.</i></p>

<p><i>Although not equivalent, the LWG is unsure if (2) is enough of
a problem to be prohibited. Points discussed in favor of allowing
(2):</i></p>

<blockquote>
  <ul>
    <li><i>It may be a convenience to implementors.</i></li>
    <li><i>The only cases that fail are structs, of which the C library
      contains only a few.</i></li>
  </ul>
</blockquote>

<p><i>]</i></p>

<p><b>Example:</b></p>

<blockquote>

<pre>#include &lt;time.h&gt;
#include &lt;utility&gt;

int main() {
    std::tm * t;
    make_pair( t, t ); // okay with version 1 due to Koenig lookup
                       // fails with version 2; make_pair not found
    return 0;
}</pre>

</blockquote>


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

<p>Replace  [depr.c.headers] paragraph 2 with:</p>

<blockquote>

<p> Each C header, whose name has the form name.h, behaves as if each
name placed in the Standard library namespace by the corresponding
cname header is also placed within the namespace scope of the
namespace std by name.h and is followed by an explicit
using-declaration (_namespace.udecl_) in global scope.</p>

</blockquote>



<p><b>Rationale:</b></p>
<p> The current wording in the standard is the result of a difficult
compromise that averted delay of the standard. Based on discussions
in Tokyo it is clear that there is no still no consensus on stricter
wording, so the issue has been closed. It is suggested that users not
write code that depends on Koenig lookup of C library functions.</p>




</body>
</html>
