From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 78cccb22 for ; Thu, 2 Jan 2020 11:31:58 +0000 (UTC) Received: (qmail 14014 invoked by alias); 2 Jan 2020 11:31:53 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45189 Received: (qmail 3840 invoked by uid 1010); 2 Jan 2020 11:31:53 -0000 X-Qmail-Scanner-Diagnostics: from out3-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25677. spamassassin: 3.4.2. Clear:RC:0(66.111.4.27):SA:0(-2.6/5.0):. Processed in 3.820079 secs); 02 Jan 2020 11:31:53 -0000 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at daniel.shahaf.name does not designate permitted sender hosts) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdeguddgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfffgrnhhivghlucfuhhgrhhgrfhdfuceougdrshesuggr nhhivghlrdhshhgrhhgrfhdrnhgrmhgvqeenucfrrghrrghmpehmrghilhhfrhhomhepug drshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvnecuvehluhhsthgvrhfuihiivgep td X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1 Mime-Version: 1.0 Message-Id: <46b2aa40-adcb-44ff-8e39-df98a9b2d235@www.fastmail.com> In-Reply-To: <64e62682e403332a89322b7f24983fa009c19fc0.camel@ntlworld.com> References: <20200101134457.kdzfrmlyzjwptxaz@tarpaulin.shahaf.local2> <64e62682e403332a89322b7f24983fa009c19fc0.camel@ntlworld.com> Date: Thu, 02 Jan 2020 11:30:54 +0000 From: "Daniel Shahaf" To: zsh-workers@zsh.org Subject: Re: Test failures in --disable-multibyte Content-Type: text/plain Peter Stephenson wrote on Wed, 01 Jan 2020 18:01 +00:00: > On Wed, 2020-01-01 at 13:44 +0000, Daniel Shahaf wrote: > > > It's not generally expected you'll want to disable multibyte explicitly, > > > but it tests the case you get if you have a system which doesn't have > > > the required multibyte support. It's not clear if zsh gets compiled on > > > such systems now --- they won't be very common but there might be some > > > deliberately reduced systems for low-level use. These only need testing > > > in a similarly limited fashion. > > > > This state of affairs doesn't sound quite right. If those codepaths > > need testing, the test suite should be made to pass in that > > configuration, so that bugfixes would be able to be tested for > > unintended side effects. With no working test suite and no known > > users, it sounds like --disable-multibyte is _de facto_ unsupported, > > but we are not ready to officially pull the plug on it due to the > > possibility of it being used on a C99-less embedded system somewhere. > > So, how about having NEWS in 5.8 say that unless someone asks us to > > continue supporting --disable-multibyte, it will become unsupported > > and may be removed? > > You're correct, it's de facto unsupported. The difference is largely > whether anyone gets around to fixing it, which is hard to predict --- I > don't think the problems are likely to be hard. So certainly it would > be useful to get interest. Alas, experience suggests most people don't > take much notice until the point where it actually stops working for > them. So as long as we point out there are problems, I think whatever > takes the least number of hostages to fortune is probably the right > thing to say. > > With the changes being largely minor and even cosmetic (but they're > certainly not all cosmetic) it probably doesn't make sense to remove > it any time soon. But it could rot further, so possibly a warning is > sensible. A build-time warning, then? I.e., have configure warn if --disable-multibyte is selected (manually or automatically), or perhaps use a #warning at the C level. It could say something to the effect of "Compiling without multibyte support is known not to pass 'make test'. We recommend to rebuild with --enable-multibyte. Alternatively, fix the test suite and send us the patches". This will at least make the issue known to anyone who tries to disable multibyte support for whatever reason.