<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/20/19 8:14 AM, Robert Douglas
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEGt33siYBjpizpWzKvOgdXbzL3aLk7La9s+iX_+NLKRxOrSgw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Will this prevent usage of printf ("func: %s",
sl.function_name ()); ?</div>
</blockquote>
<p>Can you elaborate on why you think this might be an issue?
printf expects an NTMBS. Some interesting results might be
produced for functions with names outside the basic source
character set, but how those are handled are necessarily
implementation defined.<br>
</p>
<p><tt>void f\U0001F412() {}</tt><br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite"
cite="mid:CAEGt33siYBjpizpWzKvOgdXbzL3aLk7La9s+iX_+NLKRxOrSgw@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr">On Tue, Feb 19, 2019, 6:37 PM 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:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<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's mostly an issue with filesystems with no or poor
encoding support.</div>
<div><br>
</div>
<div>I don'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 <<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="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" rel="noreferrer"
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_-1637168314054064646m_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'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 noreferrer"
target="_blank" 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"
rel="noreferrer noreferrer"
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 bgcolor="#FFFFFF">
<div
class="m_-1637168314054064646m_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 "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 noreferrer"
target="_blank"
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"
rel="noreferrer
noreferrer"
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"
rel="noreferrer
noreferrer"
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"
rel="noreferrer noreferrer" 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>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>