On 9/28/26 4:04 AM, Corentin Jabot wrote:
>
>
> On Mon, Sep 28, 2026, 05:14 Yongwei Wu via SG16
> <sg16_at_[hidden]> wrote:
>
> First, I think the paper is a fantastic summary.
>
> Second, the encoding list in the Google Sheet may contain some
> false positives. As a Chinese, I noticed the weird GBGBK
> immediately. I have no idea what it is, and googling does not
> reveal interesting results, and GBGBK does not exist on macOS
> (Sequoia) or Ubuntu (24.04 LTS). Claude Sonnet says it might be an
> internal conversion module, but it does not give much detail.
> Currently I do not think it is worthwhile to dig out what it
> really is.
>
> I think there are fewer in-use encodings that require digraphs
> than the spreadsheet implies. From what I can recognize, GBBIG5
> may be similar to GBGBK. What is ISO646 (as versus
> ISO646-something), which does not really make sense? On macOS
> there is an ISO646-BASIC:1983 (I don't see an equivalent on
> Ubuntu), but it behaves differently than the spreadsheet too.
>
>
> That table is missing some critical information: how many if these
> encodings are in common use, and used to write C++ code (or code in
> general)
>
> Or rather, the question of whether a given encoding needs digraphs is
> sort of irrelevant, the question is whether digraphs are used.
A difficult question to answer, unfortunately. Maybe our friends at IBM
can share some insight.
>
> EBCDIC-derived encodings use trigraphs and we should keep accepting
> the magical phase one mapping of trigraphs to be a conforming extension.

I don't think trigraphs can ever be a conforming extension. The
following example has well-defined behavior in ISO C++, but behaves
differently when trigraphs are enabled. https://godbolt.org/z/o3xznsrGY.

    #include <cstdio>
    int main() {
    std::printf("It's like magic: '??!'\n");
    }

> And if we really want to do encoding agnostic pragma without trigraphs
> (which there is no evidence of anyone doing today), we don't need
> digraphs.
>
> As Matthias's research shows, digraphs were a solution to a problem
> that no longer existed by the time digraphs where shoved in the
> standard, and because of internalization, internet, standardization of
> keyboards, OSes, programming languages, communication protocols and so
> forth, products that don't support the range of ASCII characters would
> not have been viable, since before the 00s.
>
> Shift JIS is the only popular encoding that is not ASCII compatible
> but we are all happy to pretend that ¥ and \ are the same character
> (same for ~/overline). Which is bonkers, but it is what it is. (Tom
> table also makes that mistake).

I just copied the data from the spreadsheet; I didn't attempt any
validation of it.

Tom.

>
>
>
> My 2 cents.
>
> On Sun, 27 Sept 2026 at 11:21, Tom Honermann via SG16
> <sg16_at_[hidden]> wrote:
>
> On 9/24/26 8:27 PM, Matthias Wippich wrote:
> > On Thu, Sep 24, 2026 at 10:20 PM Tom Honermann via SG16
> > <sg16_at_[hidden]> wrote:
> >> If possible, it would be helpful to include that content as
> an appendix in the paper itself.
> > I'll try to do that, but I'm worried that it'll be impossible to
> > format correctly. Maybe a link to a CSV export of that table
> (hosted
> > on github/gist) is sufficient? The google link might indeed
> not be
> > very stable.
>
> Any original content used to justify the motivation or design
> choices
> really should be in the paper for the historical record.
>
> Attached is a quick hack job I did that I would personally
> call good
> enough if you want to use it. The HTML isn't pretty and I
> didn't try to
> style it in any way, so there is plenty of opportunity to make
> it prettier.
>
> 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/09/4865.php
>
>
>
> --
> Yongwei Wu
> URL: http://wyw.dcweb.cn/
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Link to this post: http://lists.isocpp.org/sg16/2026/09/4866.php
>