From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master b99ec5d 3/3: Work around __has_attribute bug in clang 3.4 Date: Sat, 23 Jan 2021 11:42:28 -0800 Organization: UCLA Computer Science Department Message-ID: References: <20210122200300.770.63187@vcs0.savannah.gnu.org> <20210122200304.8BBE820A10@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------9B27F3D2EF019A8CE71D3F8D" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2452"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 Cc: Glenn Morris , emacs-devel@gnu.org To: =?UTF-8?Q?Mattias_Engdeg=c3=a5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 23 20:43:58 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 1l3OpB-0000Wj-Lp for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jan 2021 20:43:57 +0100 Original-Received: from localhost ([::1]:45834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l3OpA-0003uU-Og for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jan 2021 14:43:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59366) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l3Onr-0003Dl-Tc for emacs-devel@gnu.org; Sat, 23 Jan 2021 14:42:35 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:40910) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l3Onp-0006JC-0I; Sat, 23 Jan 2021 14:42:35 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 064B21600CC; Sat, 23 Jan 2021 11:42:30 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6isNYgvwagOe; Sat, 23 Jan 2021 11:42:28 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id B79E2160113; Sat, 23 Jan 2021 11:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EoVDoi_TouNR; Sat, 23 Jan 2021 11:42:28 -0800 (PST) Original-Received: from [192.168.1.9] (cpe-23-243-218-95.socal.res.rr.com [23.243.218.95]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8D5431600CC; Sat, 23 Jan 2021 11:42:28 -0800 (PST) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:263312 Archived-At: This is a multi-part message in MIME format. --------------9B27F3D2EF019A8CE71D3F8D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/23/21 2:11 AM, Mattias Engdeg=C3=A5rd wrote: > 23 jan. 2021 kl. 01.46 skrev Paul Eggert : >=20 >> Perhaps someone who can build on macOS directly can provide more info = about the problem. I had no problem building with clang 11.0 on Ubuntu bu= t Apple's clang is special. >=20 > Apple's clang seems to come with a builtin >=20 > #define __nonnull _Nonnull >=20 > which clashes with the the one in lib/cdefs.h. Perhaps we should call i= t something else. Thanks for the diagnosis. Although calling it something else would=20 obviously work, it would require renaming __nonnull everywhere within=20 Gnulib (and eventually Glibc), and that would be entirely contrary to=20 the intent of the Apple macro - which was to encourage compatibility=20 with GNU code. As I understand things Apple's __nonnull keyword used to=20 mean something else but collided with GNU's __nonnull macro, so they=20 renamed the keyword and put in a backward-compatibility macro for old=20 Applish code, but we don't need that macro and can just use __nonnull=20 for our own use. I attempted to fix the problem by installing the attached patch into=20 Gnulib, and then merged Gnulib into Emacs master. Please give it a try,=20 as I don't use macOS and so did not check the patch directly. Phillip is correct in theory that Gnulib (application code) should avoid=20 messing with reserved identifiers, but theory doesn't exactly equal=20 practice here because we also want to minimize differences between=20 Gnulib and Glibc. --------------9B27F3D2EF019A8CE71D3F8D Content-Type: text/x-patch; charset=UTF-8; name="0001-libc-config-port-to-Xcode-7.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-libc-config-port-to-Xcode-7.patch" =46rom 195a10b512067f18c79da0b2184689bc5520517c Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 23 Jan 2021 10:19:24 -0800 Subject: [PATCH] libc-config: port to Xcode 7 MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Problem reported by Mattias Engdeg=C3=A5rd in: https://lists.gnu.org/r/emacs-devel/2021-01/msg01089.html * lib/cdefs.h (__nonnull): If already defined but glibc is not in use, override the definition with Gnulib=E2=80=99s _GL_ATTRIBUTE_NONNULL.= This is needed for Xcode 7, which has a =E2=80=98#define __nonnull _Nonnull=E2=80=99 builtin for backwards-compatibility with an older Xcode= syntax that GNUish code never uses. --- ChangeLog | 11 +++++++++++ lib/cdefs.h | 6 ++++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index b1b81353e..43d1a1671 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,14 @@ +2021-01-23 Paul Eggert + + libc-config: port to Xcode 7 + Problem reported by Mattias Engdeg=C3=A5rd in: + https://lists.gnu.org/r/emacs-devel/2021-01/msg01089.html + * lib/cdefs.h (__nonnull): If already defined but glibc is not in + use, override the definition with Gnulib=E2=80=99s _GL_ATTRIBUTE_NONNUL= L. + This is needed for Xcode 7, which has a =E2=80=98#define __nonnull + _Nonnull=E2=80=99 builtin for backwards-compatibility with an older Xco= de + syntax that GNUish code never uses. + 2021-01-23 Bastien Roucari=C3=A8s =20 explicit_bzero: Add fallback for other compilers. diff --git a/lib/cdefs.h b/lib/cdefs.h index 060a3d068..6f12c79da 100644 --- a/lib/cdefs.h +++ b/lib/cdefs.h @@ -320,14 +320,16 @@ #endif =20 /* The nonnull function attribute marks pointer parameters that - must not be NULL. Do not define __nonnull if it is already defined, - for portability when this file is used in Gnulib. */ + must not be NULL. */ #ifndef __nonnull # if __GNUC_PREREQ (3,3) || __glibc_has_attribute (__nonnull__) # define __nonnull(params) __attribute__ ((__nonnull__ params)) # else # define __nonnull(params) # endif +#elif !defined __GLIBC__ +# undef __nonnull +# define __nonnull(params) _GL_ATTRIBUTE_NONNULL (params) #endif =20 /* If fortification mode, we warn about unused results of certain --=20 2.27.0 --------------9B27F3D2EF019A8CE71D3F8D--