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.