They come from different sources. Function name is in the source encoding, and the compiler knows that encoding. The file name is in the host environment, and we don't know, and in some cases can't know, what that is. Display names may not work for opening a file again. <br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 19, 2019, 14:31 Robert Douglas <<a href="mailto:rwdougla@gmail.com">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="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 <<a href="mailto:Axel.Naumann@cern.ch" target="_blank">Axel.Naumann@cern.ch</a>> 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'll take to Core.<br>
Axel.<br>
<br>
<div class="m_-1975568419659587734m_4944719826335876746moz-cite-prefix">On 19.02.19 13:58, Corentin wrote:<br>
</div>
<blockquote type="cite">
<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" rel="noreferrer" 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" rel="noreferrer" 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_-1975568419659587734m_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
"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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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>
</blockquote>
<br>
</div>
</blockquote></div>
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div>