<div dir="auto">Will this prevent usage of printf ("func: %s", sl.function_name ()); ?</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 19, 2019, 6:37 PM Corentin <<a href="mailto:corentin.jabot@gmail.com">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">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">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">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">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">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">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">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">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>