From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id A6FC53858D39 for ; Tue, 9 Nov 2021 11:38:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A6FC53858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1636457895; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=0/mR+wvczq8x1YjTFKW1mXjA9NWg5xsxA6REwvKpfUI=; b=Rui4FFb//wqXFTjB+qjN2IWjnOHBDEUvXJe+s/zSoTPIHN+n73+sLLS/7KWWZM5DyQHHV8 ezaxJ23X7bLAWl/6gWwpdyvl3hCkwKuEq3HS8o6Y3ytYA5BigysxhhFIkD3fsXptlc4jYV NjaZ4TaQctQS7QKEXsBV6OaWZkBOLUQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-450-Drs6DeBPNqGCtf4EHMO8-g-1; Tue, 09 Nov 2021 06:38:13 -0500 X-MC-Unique: Drs6DeBPNqGCtf4EHMO8-g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 173E9A0BC5 for ; Tue, 9 Nov 2021 11:38:04 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-112-10.ams2.redhat.com [10.36.112.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DBEA65DEFA for ; Tue, 9 Nov 2021 11:38:03 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id 7A5F4A80D44; Tue, 9 Nov 2021 12:38:02 +0100 (CET) Date: Tue, 9 Nov 2021 12:38:02 +0100 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: [PATCH 2/2] ctype: use less short names in public header Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org References: <20211109012447.30698-1-vapier@gentoo.org> <20211109012459.30826-1-vapier@gentoo.org> MIME-Version: 1.0 In-Reply-To: <20211109012459.30826-1-vapier@gentoo.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vinschen@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 11:38:16 -0000 On Nov 8 20:24, Mike Frysinger wrote: > We're seeing a build failure in GNU sim code which is using _P locally > but the ctype.h define clashes with it. Rename these to use the same > symbols that glibc does. They're a bit more verbose, but seems likely > that we'll have fewer conflicts if glibc isn't seeing them. ^^^^^ Mixing newlib and glibc? That's just a typo, I guess? > However, these shortnames are still used internally by ctype modules > to produce pretty concise source code, so use _COMPILING_NEWLIB to > keep them around when compiling newlib itself where we have better > control over short name conflicts. Hmm. I'm not sure we should really maintain two different sets of symbols. I think it would be better to go the entire way and replace the single letter symbols with the new, more speaking ones throughout. There are not that many affected files and the change might be done with sed mostly. The only exceptions *could* be libc/ctype/ctype_.c and the local ctype_iso.h and ctype_cp.h headers it includes. A local definition of the single letter symbols in ctype_.c would be sufficient then. But even there we might be better off with the new symbols in the long run... Corinna