On 12/8/20 6:13 AM, Peter Brett via SG16 wrote:
Hi Niall,

I'm pretty sure that you shouldn't have reported this outside WG14.

A reminder to all that the SG16 mailing list is a public list with public archives and is subject to the WG21 code of conduct and ISO code of conduct.  By posting these links, I am not alleging that a CoC violation has occurred here.  If anyone feels that there has been a violation, please follow the processes described in those documents.

Nial, ISO rules are intended to allow members to communicate within ISO meetings with reasonable expectations of privacy; they may choose to make statements in ISO meetings that they may choose not to make publicly.  How a member votes within an ISO meeting is privileged information.  You did not share particulars of how a member voted on any particular issue here, but sharing your perception of what motivates a member's vote is, at least, poor form; in this case, how a member votes was not even relevant to the topic of discussion.  Please refrain from comments regarding member's votes or voting habits in the future.

Your other comments are appreciated, thank you.



-----Original Message-----
From: SG16 <sg16-bounces@lists.isocpp.org> On Behalf Of Niall Douglas via
Sent: 08 December 2020 11:12
To: sg16@lists.isocpp.org
Cc: Niall Douglas <s_sourceforge@nedprod.com>
Subject: Re: [SG16] [ WG14 ] Mixed Wide String Literals


On 07/12/2020 22:56, Tom Honermann via SG16 wrote:

IBM does maintain representation in WG21 (and I thought in WG14 as
well).  There are also ports of Clang to EBCDIC systems now as well.
They have robust representation on WG14. Indeed, they are the primary
cause for saying no to any proposed insubstantial change. This is very
frustrating to anyone proposing anything non-trivial, but the IBM rep is
a very good engineer, very technically able, and he has a strong opinion
that C ought to not change by much, ever.

IBM remains keen on EBCDIC, and they defend it on WG14 zealously. I'd
say everybody else on WG14 would prefer if it went away, but in the end
if a particular implementor really wants to support it, there aren't
good reasons for removing it.

SG16 mailing list