<div dir="ltr">It kinda is but the compiler can get a useful encoding from the source code but not from the source file, in the general case.<div>It&#39;s mostly an issue with filesystems with no or poor encoding support.</div><div><br></div><div>I don&#39;t believe the observable behavior will be widely different from __FILE__ and __func__ in practical terms</div><div><div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Feb 2019 at 14:31 Robert Douglas &lt;<a href="mailto:rwdougla@gmail.com">rwdougla@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">So filename and functionname would neccessarily have different encodings? Does that not seem awful?</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 19, 2019, 6:25 PM Axel Naumann &lt;<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Thanks everyone, this is what I&#39;ll take to Core.<br>
    Axel.<br>
    <br>
    <div class="m_6886386620876239615m_4944719826335876746moz-cite-prefix">On 19.02.19 13:58, Corentin wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">After talking with Tom, I&#39;d like to modify
        function_name to be a NTMBS as it is something we can actually
        guarantee and I don&#39;t think <font face="monospace">__func__</font>
        should constrain the design of source location. It would
        consistent with thTstatisfy the NB comment (whose resolution was
        adopted in that direction this morning)
        <div><br>
        </div>
        <div>Tom convinced me that filename cannot and should not be a
          NTMBS<br>
          <div><span style="font-family:monospace,monospace"><br>
            </span></div>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Tue, 19 Feb 2019 at
              13:22 Robert Douglas &lt;<a href="mailto:rwdougla@gmail.com" rel="noreferrer" target="_blank">rwdougla@gmail.com</a>&gt; wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">Agree. <br>
              </div>
              <br>
              <div class="gmail_quote">
                <div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019
                  at 5:17 PM Tom Honermann &lt;<a href="mailto:tom@honermann.net" rel="noreferrer" target="_blank">tom@honermann.net</a>&gt;
                  wrote:<br>
                </div>
                <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                  <div bgcolor="#FFFFFF">
                    <div class="m_6886386620876239615m_4944719826335876746m_-1850481202019439280m_-3567928716533211423gmail-m_-4999753202126389113moz-cite-prefix">On
                      2/18/19 1:17 PM, Robert Douglas wrote:<br>
                    </div>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div dir="ltr">
                          <div dir="ltr">Historical footnote, these are
                            intended to be as drop-in as possible for
                            existing facilities. __FILE__ is a
                            &quot;character string literal,&quot; which gets it&#39;s
                            null termination in phase 7. Since we are
                            accessing these at run-time, we should thus
                            expect these to be NTBS. Changes to this
                            expectation would be a deviation from these
                            being a drop-in replacement to __FILE__ and
                            __func__. Note that [dcl.fct.def.general]<br>
                          </div>
                          <div> p 8 defines __func__ as an
                            implementation-defined string as if <span style="font-family:monospace,monospace">static
                              const char __func__[] = &quot;function-name &quot;;</span>
                            which implies, also, an NTBS. This is the
                            reasoning for NTBS. To do otherwise, would
                            deviate this feature from __FILE__ and
                            __func__, which it is designed to replace.<br>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                    <p>Agreed.  Certainly guaranteeing that these have a
                      null terminator is required given that file_name()
                      returns const char*.  I don&#39;t agree with
                      associating these with NTMBSs though since
                      multi-byte has encoding implications.<br>
                    </p>
                    <p>Tom.<br>
                    </p>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div dir="ltr">
                          <div><br>
                          </div>
                        </div>
                      </div>
                      <br>
                      <div class="gmail_quote">
                        <div dir="ltr" class="gmail_attr">On Mon, Feb
                          18, 2019 at 11:20 AM Corentin &lt;<a href="mailto:corentin.jabot@gmail.com" rel="noreferrer" target="_blank">corentin.jabot@gmail.com</a>&gt;
                          wrote:<br>
                        </div>
                        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quick reply
                          : display only, no expectation the file can be
                          open, or exists, or is a file. It&#39;s purely
                          informative. But expectation it can be
                          displayed, the main use cases being logging.
                          Otherwise I agree with you.<br>
                          <br>
                          <div class="gmail_quote">
                            <div dir="ltr">On Mon, Feb 18, 2019, 7:16 AM
                              Tom Honermann &lt;<a href="mailto:tom@honermann.net" rel="noreferrer" target="_blank">tom@honermann.net</a>&gt;
                              wrote:<br>
                            </div>
                            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                              <div dir="auto"><br>
                                <div dir="ltr">On Feb 18, 2019, at 10:04
                                  AM, Corentin &lt;<a href="mailto:corentin.jabot@gmail.com" rel="noreferrer" target="_blank">corentin.jabot@gmail.com</a>&gt;
                                  wrote:<br>
                                  <br>
                                </div>
                                <blockquote type="cite">
                                  <div dir="ltr">
                                    <div dir="ltr"><br>
                                      <div>Very good points. </div>
                                      <div>Wouldn&#39;t it be sufficient to
                                        specify that the strings are
                                        NTMBS encoded using the
                                        execution character set?</div>
                                    </div>
                                  </div>
                                </blockquote>
                                <blockquote type="cite">
                                  <div dir="ltr">
                                    <div dir="ltr">
                                      <div>source_location currently
                                        avoids making any assumption
                                        about how these strings are
                                        formed, including that they are
                                        derived from a source file.</div>
                                      <div>So since the value is
                                        implementation-defined, so
                                        should be the way it&#39;s
                                        constructed. </div>
                                      <div>However, it is reasonable to
                                        assume that these things are
                                        valid text and therefore have a
                                        known encoding.</div>
                                      <div><br>
                                      </div>
                                      <div>Adding Tom, because this is
                                        borderline SG16 territory. </div>
                                    </div>
                                  </div>
                                </blockquote>
                                <div><br>
                                </div>
                                <div>This isn’t borderline as we have
                                  (recently) requested review of
                                  anything involving file names. </div>
                                <br>
                                <blockquote type="cite">
                                  <div dir="ltr">
                                    <div dir="ltr">
                                      <div><br>
                                      </div>
                                      <div><br>
                                      </div>
                                      <div>@Tom: Do you want to see
                                        source_location this week
                                        knowing that I&#39;d hope it would
                                        get through LWG before the end
                                        of the week?</div>
                                      <div>Or do you think
                                        having function_name / filename
                                        as multi-bytes strings encoded
                                        using the execution character
                                        set is reasonable?</div>
                                      <div>The alternative I see are</div>
                                      <div>
                                        <ul>
                                          <li><font size="2">Leave it
                                              unspecified</font></li>
                                          <li><font size="2">Force a
                                              specific character set...
                                              which the world is not
                                              ready for</font></li>
                                        </ul>
                                      </div>
                                    </div>
                                  </div>
                                </blockquote>
                                <div>I think there is a higher level
                                  question to answer. Are the provided
                                  file names display only, or should one
                                  expect to be able to open the file
                                  using the provided name?</div>
                                <div><br>
                                </div>
                                <div>If they are display only, then we
                                  can specify an encoding for them
                                  similarly to what is done for member
                                  functions of std::filesystem::path. In
                                  this case, we must explicitly
                                  acknowledge that the names do not
                                  roundtrip through the filesystem
                                  (though typically will in practice).
                                  Note that, on <span style="background-color:rgba(255,255,255,0)">Windows,
                                    file names cannot be represented
                                    accurately using char based strings,
                                    so unless we want to add wchar_t
                                    support, these names will be
                                    technically display only. </span></div>
                                <div><br>
                                </div>
                                If they are potentially not display
                                only, then we can’t associate an
                                encoding and the names are
                                bags-of-bytes. This is a limitation of
                                POSIX. But then we need wchar_t support
                                for Windows. 
                                <div><br>
                                </div>
                                <div>In San Diego, the guidance we gave
                                  for the stacktrace proposal is that
                                  file names are  implementation
                                  defined <span style="background-color:rgba(255,255,255,0)">bags-of-bytes.
                                    If we advised otherwise for source
                                    location, we would be giving
                                    inconsistent guidance. </span></div>
                                <div><br>
                                </div>
                                <div>I think we should discuss this in
                                  SG16 this week. Not necessarily to
                                  propose changes for the proposal, but
                                  to solidify our collective thinking
                                  around file names. </div>
                              </div>
                              <div dir="auto">
                                <div><br>
                                </div>
                                <div>Tom. <br>
                                  <div>
                                    <blockquote type="cite">
                                      <div dir="ltr">
                                        <div dir="ltr">
                                          <div><br>
                                          </div>
                                          <div>Thanks, </div>
                                          <div>Corentin</div>
                                          <div><br>
                                          </div>
                                          <div><br>
                                          </div>
                                          <br>
                                          <div class="gmail_quote">
                                            <div dir="ltr" class="gmail_attr">On Mon,
                                              18 Feb 2019 at 03:56 Axel
                                              Naumann &lt;<a href="mailto:Axel.Naumann@cern.ch" rel="noreferrer" target="_blank">Axel.Naumann@cern.ch</a>&gt;
                                              wrote:<br>
                                            </div>
                                            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
                                              Robert,<br>
                                              <br>
                                              Regarding your P1208R3:<br>
                                              <br>
                                              Nit: it&#39;s titled
                                              &quot;D1208R3&quot;, it doesn&#39;t
                                              mention email addresses.<br>
                                              <br>
                                              Not-so-nit: a NB comment
                                              on the reflection TS asks
                                              to not use NTBS but<br>
                                              NTMBS and &quot;Where NTBS is
                                              mentioned in the document
                                              under ballot, the<br>
                                              encoding used for the
                                              string’s value is
                                              unspecified.&quot; Jens agrees
                                              that<br>
                                              the proposed solution
                                              should be applied:
                                              &quot;Specify that the strings
                                              are<br>
                                              first formed using the
                                              basic source character set
                                              (with<br>
                                              universal-character-names
                                              as necessary) then mapped
                                              in the manner<br>
                                              applied to string literals
                                              with no encoding prefix in
                                              phases 5 and 6 of<br>
                                              translation.&quot;<br>
                                              <br>
                                              I would very much hope
                                              that both changes are also
                                              applied to P1208R3. I<br>
                                              call this out explicitly
                                              in our recommended NB
                                              comment response paper.<br>
                                              <br>
                                              Cheers, Axel.<br>
                                            </blockquote>
                                          </div>
                                        </div>
                                      </div>
                                    </blockquote>
                                  </div>
                                </div>
                              </div>
                            </blockquote>
                          </div>
                        </blockquote>
                      </div>
                    </blockquote>
                    <p><br>
                    </p>
                  </div>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div>
</blockquote></div>