From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 541FC1F63E for ; Sun, 29 Jan 2023 23:21:19 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=clisp.org header.i=@clisp.org header.a=rsa-sha256 header.s=strato-dkim-0002 header.b=UD1ddK+z; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMGyy-0001dg-3K; Sun, 29 Jan 2023 18:21:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMGyv-0001dJ-Vi for bug-gnulib@gnu.org; Sun, 29 Jan 2023 18:21:05 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMGyt-0006R7-VG for bug-gnulib@gnu.org; Sun, 29 Jan 2023 18:21:05 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1675034460; cv=none; d=strato.com; s=strato-dkim-0002; b=m7dCmyq2eaJm4hvVHTwBsDc9/INp3L4ai9oAjZQGs0J4VYMxz6zvcFp0QOptX0lUb7 XprvO1llNUC5vlGY9E+0BRuxVfvkb1Jf6+0VcWBEfPUTlXzY6G1WYzBOKtOLKJWBp9sF xgxBaKikBXZ93M+baF2+sTKAk0dV2ZulI3cGne/d9hQXVr4l3/bbQu3TW6dq8VeBhXxs fKd5JR9YhXj95ip4H4LqL27o3DtGI94TEfJm3cVX/QnP0q+mlo+tktwgM/GQcM9efQY/ hAvYfWejEkDD70zWCpmHedp1H+mvp4HBGD7mdPdX1iJDiqAe9Ic/7abbp8ohY1BTTgUN sTDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1675034460; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=KldYu+fJwRueAlB/q9X5KtxmfHwJOg5joUkODoJr+mk=; b=c0hnnOF8ypfIcb85rIHuX6YGeHD844RfrQgjj67rezaQv7QJEEFsjiXKQ4GpPuhHLB wcbGHDIskHCCHukYCRH8mWvBhsiD+C5bLByQMWm7cbvfL4ouy4bNL+BC9vnEgTfyyFub 5wIln/yesInUCnHjOjfdk6LsV+D6eq//2ue1D3KOScUDg7sthhD9ctYZzhchY7UhGUye GaITqz6B2wT/PDb64wOIqeeDPenXamT3KciFP6diTXEF57TMGRd4UvBr3lVBR25jCKoq 5rCsNKhYqZbrGvhTqMZ1Wc8hEdIx7FIW4J/chJp2w9l4X9r5tsiyJZkRaMrOShbvp17T AVtQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1675034460; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=KldYu+fJwRueAlB/q9X5KtxmfHwJOg5joUkODoJr+mk=; b=UD1ddK+zCmLjjsRD6f4yIx1RmoKQ1ahOIYDAnyopPt3X4Go7JRg8SjRIrOFxHwZLGE Txh7w9CBFFxx29dbrRTQSKrBYrLYXCAISJCd4Z75wcoPbkGg3p29e2XAyUVMKmzVF28l PUpJvgZ+d05MQjAoqh9f4BGunSGyf+46ESyk4LYb+e+gIC9wIUYbwHIgiLT1i4NL8WAr 5dvhQdenCWA+G4MeE1B+bLvz8DzwxCbH2UIl1stO4f93L/DQricEwqUa0usmL/7jjBW2 VRtKmDKF356C5zlcADUvOS+cROS2D7W2EhJ+nGLFZeVHwP0EuR4QTxhx6dpaYt7aPus3 Goag== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPF3KZI9ilgtRRA2BFjBWDjzg8H" Received: from nimes.localnet by smtp.strato.de (RZmta 49.2.2 AUTH) with ESMTPSA id 098542z0TNL0Por (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 30 Jan 2023 00:21:00 +0100 (CET) From: Bruno Haible To: bug-gnulib@gnu.org Subject: libc-config and system-reserved symbols Date: Mon, 30 Jan 2023 00:20:59 +0100 Message-ID: <6109082.vxZlqCtKo7@nimes> In-Reply-To: <4215786.ePpL0Tn3zg@nimes> References: <4215786.ePpL0Tn3zg@nimes> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.25; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Hi Paul, I wrote: > The cause is that Android has its own framework for defining fortified > variants of the string operations, and like glibc it uses macros named > '__bos' and '__bos0'. But these macros have different definitions in > Android than in glibc. This situation can happen with any symbols that are prefixed with __ and are therefore system-reserved. As far as I understand, the general approach of this cdefs.h is that it defines __ prefixed macros for glibc, and there are two categories: (A) Those that become active in gnulib as well. (B) Those that are not active in gnulib. For porting more code from glibc to gnulib, and for avoiding surprises when pulling new versions of existing modules from glibc to gnulib, it is useful when the set (A) is large. On the other hand, to avoid conflicts with existing platforms, the set (A) should be small. Today, I moved the Fortify-related symbols from (A) to (B). But I claim that the set (A) is still too large. 1) Look at the defined symbols: Some, such as __P, __PMT, etc. are not used by the code that Gnulib borrows from glibc. Each such symbol could have a meaning different from the glibc one on some platform. 2) Speaking specifically about Android, I compared the definitions. After eliminating equivalentr definitions, the remainder is: Gnulib : # define __inline inline # define __inline /* No inline functions. */ # define __THROW # define __THROWNL # define __NTH(fct) fct #define __CONCAT(x,y) x ## y #define __STRING(x) #x #define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL > 1) #define __bos0(ptr) __builtin_object_size (ptr, 0) # define __warnattr(msg) __attribute__((__warning__ (msg))) # define __warnattr(msg) # define __attribute_warn_unused_result__ \ # define __wur __attribute_warn_unused_result__ # define __attribute_warn_unused_result__ /* empty */ # define __always_inline __inline __attribute__ ((__always_inline__)) # define __always_inline __inline # define __extern_inline extern __inline __attribute__ ((__gnu_inline__)) # define __extern_always_inline \ # define __extern_inline extern __inline # define __extern_always_inline extern __always_inline Android : #define __CONCAT1(x,y) x ## y #define __CONCAT(x,y) __CONCAT1(x,y) #define ___CONCAT(x,y) __CONCAT(x,y) #define __inline inline /* convert to C++ keyword */ #define __always_inline __attribute__((__always_inline__)) #define __warnattr(msg) __attribute__((deprecated(msg))) #define __bos(s) __bosn((s), __bos_level) # define __bos0(s) __bosn((s), 0) Notice in particular: - the different definitions of __CONCAT - the different definitions of __inline - the different definitions of __always_inline - the different definitions of __warnattr I would not be surprised if these macros cause trouble, either on Android or on other platforms, in the future. Bruno