C++ Logo


Advanced search

Re: [SG16] Structure of EBCDIC MBCS and wide EBCDIC

From: Corentin Jabot <corentinjabot_at_[hidden]>
Date: Thu, 14 Oct 2021 13:38:15 +0200
On Thu, Oct 14, 2021 at 1:19 PM Jens Maurer via SG16 <sg16_at_[hidden]>

> On 14/10/2021 03.05, Tom Honermann wrote:
> > Thank you, Jens and Hubert for this further discussion.
> >
> > I think these are important points for the paper to address. However, I
> don't think they materially affect the design intent, so I'm not inclined
> to revisit the SG16 consensus. Please let me know if you feel this is new
> information that warrants another trip through SG16.
> We need (preferably normative) text that says that wide_literal()
> (and possibly wide_environment()) talk about the object representation.
> The "object representation" part was discussed earlier, but I haven't
> seen an update with that. (Maybe I've missed it.)

That was done https://isocpp.org/files/papers/P1885R8.pdf

> The current talk about plain encoding leads us to the Core section,
> where the object representation is exactly not a concern.

> I think we can also enhance wide_literal() and wide_environment()
> to say normatively that UTF16BE/LE and UTF32BE/LE is never returned,
> but instead UTF-16/UTF-32 with a special deviation from the ISO 10646
> definition. (We also discussed this earlier.)

Also done

> Since the latter changes what is in a normative reference, I think we
> need to show this alteration of semantics in normative text.
> Side note: What's the "environment" in wide_environment() to start with?
> Where is it defined? How does it affect the semantics of the rest of the
> standard?

There is a note that says that it does not affect the semantics of the rest
of the standard

> Tom, if you believe this doesn't need a re-review in SG16, that's fine,
> but of course that risks LEWG sending the paper back to SG16.
> > Corentin, I suggest doing the following:
> [...]
> > * Add guidelines for registering wide encodings with IANA; e.g.,
> recommended naming conventions and native endian encodings (potentially in
> addition to BE/LE encodings that might be used for octet based interchange).
> Nobody suggest to register anything with IANA, I believe, so I don't know
> what
> you mean here.
> > * Add normative encouragement that, e.g., UTF-16 should not be
> returned for wide_literal() and wide_environment() when sizeof(wchar_t) is
> other than 1 or 2.
> I think we can positively prohibit that (either explicitly or implicitly),
> because
> sizeof(wchar_t) > 2 means the object representation can't ever be UTF-16.

That was my hope, also by talking about encoding scheme explicitly

> Jens
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16

Received on 2021-10-14 06:38:28