From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-28 9c222b9: Port to C compilers that lack size-0 arrays Date: Fri, 03 Dec 2021 22:01:53 +0200 Message-ID: <83lf1178zy.fsf@gnu.org> References: <83bl1y85np.fsf@gnu.org> <83tufp7dae.fsf@gnu.org> <18c9aeb7-3b9e-3e94-a24b-b52ea10ce75d@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28187"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 03 21:03:13 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mtEm1-00077N-0b for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Dec 2021 21:03:13 +0100 Original-Received: from localhost ([::1]:47310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtElz-000392-H9 for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Dec 2021 15:03:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtEku-0002Rd-Gq for emacs-devel@gnu.org; Fri, 03 Dec 2021 15:02:04 -0500 Original-Received: from [2001:470:142:3::e] (port=48650 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtEkt-0005zn-LN; Fri, 03 Dec 2021 15:02:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=laadfacrR8iCOrlopqP4x4SI1qVYJXI5zptwMI/9Ffc=; b=TBQwwvcswpzH gyTY9FiKYMu+CkdnEii5oCneVKVsrDBYamUsRk4gzkqJ/ER78Xlb6C3B0WuK6eWCQhCutiTpqj43L OLHkjfYHaAzuEdW29ZB0dbyxaoGTIT/y36ACzZsPBJMF3qTx11Umowgk3JrMPsZ20ewaLmiKh1x3T nuXPtneOjaJYYe1kGOtXFDuSnMqpNlaftJDoEUhUwTfB/NUDu2+aYv6JGRvKVTOTJS48CL+J6z0a6 v2urn8NhEWShUkAJ7eschuC/oiljgZkLSRtAfIjmesRk+9l8bIdtlG/h9kOC5cHpX7YqpCcATwl2q uMZIeJ+RCasAIoWE8Tcx1A==; Original-Received: from [87.69.77.57] (port=3882 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtEkt-0004wv-An; Fri, 03 Dec 2021 15:02:03 -0500 In-Reply-To: <18c9aeb7-3b9e-3e94-a24b-b52ea10ce75d@cs.ucla.edu> (message from Paul Eggert on Fri, 3 Dec 2021 11:42:08 -0800) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280869 Archived-At: > Date: Fri, 3 Dec 2021 11:42:08 -0800 > Cc: emacs-devel@gnu.org > From: Paul Eggert > > On 12/3/21 10:29, Eli Zaretskii wrote: > >> What I experienced was a ton of diagnostics with both the Oracle Solaris > >> and the IBM AIX C compilers, which made it difficult for me to see the > >> real problems on those platforms (of which there were some). > > Any reason why we should be concerned about these two platforms? > > Emacs has run on Solaris and AIX for decades, these platforms are stable > and are supported by Oracle and IBM respectively, and there's very > little trouble keeping Emacs working on these platforms. Emacs still did compile on those platforms before your changes. So we are not talking about dropping support for them or breaking the build on them, we are talking about avoiding warnings. > And it's not just these two platforms. My bigger motivation for this > particular change was that the old code violates a constraint specified > by the C standard. Even though the old code works on GCC, Clang and > MSVC, there's a reasonable chance it won't work on less-commonly-used > compilers and there's little point to taking that risk when the fix is > so simple. That's okay, but such cleanup changes should be done on master, not on the release branch during a pretest. The time for cleanups on the release branch has come and gone. (And we don't support MSVC builds for a very long time now.) So I'm inclined to revert that changeset on the release branch.