This meeting will start in ~5 minutes!

Tom.

On 5/28/25 12:47 AM, Tom Honermann via SG16 wrote:
>
> SG16 will hold a meeting *today/tomorrow*, Wednesday, May 28th, at
> 19:30 UTC (timezone conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250528T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>).
>
> If you need a .ics file to import into your calendar, you can download
> it here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/5FDDA8FA-1102-44AC-8E03-DC78F1B95BB6.ics?export>.
>
> The agenda follows.
>
> * P3671R0: Clarifying the interaction of the literal and execution
> encodings <https://wg21.link/p3671r0>.
> * P3677R0: Preserving LC_CTYPE at program start for UTF-8 locales
> <https://wg21.link/p3677r0>.
>
> This will be yet another celebration of Corentin and his prolific
> paper writing abilities!
>
> *P3671R0* seeks to make the C++ standard more explicit with regard to
> expected behavior (or lack thereof) when either the ordinary/wide
> literal encoding or the corresponding encoding of the execution
> (wide-)character set includes characters in its repertoire that are
> either not representable or are represented differently in the other
> encoding. The proposal adds non-normative notes to the standard that
> clarify that mojibake may result in unexpected/undefined behavior.
>
> *P3677R0* targets both C (WG14) and C++ (WG21). It seeks to do for C
> and C++ what PEP-538 <https://peps.python.org/pep-0538/> did for
> Python; to preserve the environment locale encoding when it is UTF-8
> while also preserving the historical behavior that C and C++ programs
> start as if an implicit call to setlocale(LC_ALL, "C") was made.
> Basically, it says that, on a system that has a "C.utf8" locale, if
> the environment locale the program is started in uses UTF-8 (e.g.,
> "en_US.utf8"), then the behavior is as if an implicit call to
> setlocale(LC_ALL, "C.utf8") was performed instead.
>
> Tom.
>
>