<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
I believe this awfulness reflects reality.<br>
<br>
Use ASCII printable characters and all will be fine? :)<br>
<br>
Axel.<br>
<br>
<div class="moz-cite-prefix">On 19.02.19 14:31, Robert Douglas
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEGt33s36c+cmGft8HU401bwLuVA6xL42LEz-Z0zU7kiKcs4fg@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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_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" target="_blank"
rel="noreferrer" moz-do-not-send="true">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" rel="noreferrer"
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 bgcolor="#FFFFFF">
<div
class="m_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"
target="_blank" rel="noreferrer"
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" rel="noreferrer"
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"
rel="noreferrer"
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"
rel="noreferrer"
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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>