<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/18/19 1:17 PM, Robert Douglas
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEGt33v2EQLADo2-ScVbdHb=hhqLO2CBjqjMiLY1U9BXBfnOPg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
cite="mid:CAEGt33v2EQLADo2-ScVbdHb=hhqLO2CBjqjMiLY1U9BXBfnOPg@mail.gmail.com">
<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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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>
</body>
</html>