<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><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">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">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">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">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>