On 2/23/26 11:16 AM, Hubert Tong wrote:
> On Sun, Feb 22, 2026 at 12:33 PM Jan Schultke via SG16
> <sg16_at_[hidden]> wrote:
>
> Some of the concerns that have arisen so far are being addressed
> in https://isocpp.org/files/papers/P3876R1.html, which is going to
> be in Monday's mailing.
>
>
> FWIW, I have confirmed that `strtod` on z/OS uses the "byte"
> interpretation of "character": it does not ignore redundant shift
> sequences in the string.

Thanks, Hubert! That is very helpful information!

Tom.

>
> -- HT
>
>
> On Sat, 21 Feb 2026 at 20:48, Tom Honermann <tom_at_[hidden]> wrote:
>
> My rough notes for this meeting are available on the (✨NEW!✨)
> WG21 wiki here
> <https://wiki.isocpp.org/2026_Telecons:SG16Teleconference2026-02-11>.
>
> The P3876 GH issue
> <https://github.com/cplusplus/papers/issues/2549> has been
> updated to indicate that SG16 review has not concluded and
> that we are now awaiting a revision with updated wording.
>
> As promised, Corentin initiated a thread on the SG16 mailing
> list <https://lists.isocpp.org/sg16/2026/02/4670.php>
> concerning use of the "literal encoding" in standard library
> wording where the "encoding of the C locale" might be more
> appropriate. Please review and offer any comments there.
>
> Jan filed LWG 4522 (Clarify that std::format transcodes for
> std::wformat strings)
> <https://cplusplus.github.io/LWG/issue4522> to follow up on
> the observation that numeric formatting specified in terms of
> to_chars() requires transcoding when formatting for
> wide-character strings.
>
> Tom.
>
> On 2/10/26 10:02 PM, Tom Honermann via SG16 wrote:
>>
>> SG16 will hold a meeting *tomorrow*, Wednesday, February
>> 11th, at 19:30 UTC (timezone conversion
>> <https://www.timeanddate.com/worldclock/converter.html?iso=20260211T193000&p1=1440&p2=tz_pst&p3=tz_mst&p4=tz_cst&p5=tz_est&p6=tz_cet>).
>>
>> The agenda is:
>>
>> * P3876R0: Extending <charconv> support to more character
>> types <https://wg21.link/p3876r0>.
>> * P3904R0: When paths go WTF: making formatting lossless
>> <https://wg21.link/p3904r0>.
>>
>> This is the same agenda as our last meeting on 2026-01-28
>> <https://wiki.isocpp.org/2026_Telecons:SG16Teleconference2026-01-28>.
>> As you may recall, we spent the entire meeting discussing
>> *P3876R0*, but did not quite conclude the discussion. We took
>> six polls, all of which confirmed the direction of the paper.
>> In this meeting, we'll review the wording and if all goes
>> well, poll to forward.
>>
>> *P3904R0* seeks to preserve the values of code units that are
>> not part of a well-defined Unicode code unit sequence (e.g.,
>> a lone surrogate) when formatting std::filesystem::path
>> objects for the ordinary literal encoding when that encoding
>> is UTF-8. The idea is, given an ill-formed code unit sequence
>> (e.g., L'\xD800'), rather than encoding a U+FFFD replacement
>> character, to encode the code unit value in WTF-8
>> <https://wtf-8.codeberg.page/>; an extension of UTF-8 that
>> encodes lone surrogate code points as if they were valid
>> Unicode scalar values. This transformation has the downside
>> of producing text that is not well-formed UTF-8 (substituting
>> a replacement character ensures well-formed UTF-8), but has
>> the upside of preserving invalid code unit sequences in a way
>> that allows the original path to be recovered. Note that
>> common filesystems that use 16-bit code units, such as on
>> Windows, do not require filesystem paths to be well-formed
>> UTF-16. Also note that std::format() and std::print() support
>> use of the "?" formatting option to produce a value
>> preserving rendering of ill-formed code unit sequences; given
>> a lone surrogate such as U+D800, use of that option would
>> produce "\u{d800}" instead of a replacement character today.
>> We therefore have a way to do round-trip preservation of
>> filesystem paths today (but not via WTF-8; at least not
>> without an additional explicit translation step).
>>
>> Tom.
>>
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2026/02/4673.php
>