<div dir="ltr">After talking with Tom, I'd like to modify function_name to be a NTMBS as it is something we can actually guarantee and I don'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 <<a href="mailto:rwdougla@gmail.com" target="_blank">rwdougla@gmail.com</a>> 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 <<a href="mailto:tom@honermann.net" target="_blank">tom@honermann.net</a>> 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_-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 "character string literal," which gets it'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__[] = "function-name ";</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'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 <<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>>
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'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
<<a href="mailto:tom@honermann.net" target="_blank">tom@honermann.net</a>> 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
<<a href="mailto:corentin.jabot@gmail.com" target="_blank">corentin.jabot@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
<div>Very good points. </div>
<div>Wouldn'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'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'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 <<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>>
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's titled "D1208R3", it doesn'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 "Where NTBS is mentioned in the
document under ballot, the<br>
encoding used for the string’s value is
unspecified." Jens agrees that<br>
the proposed solution should be applied:
"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."<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>