From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (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 9BDE31F453 for ; Mon, 21 Jan 2019 18:22:27 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=LnOCl p/Oa1o/GL30ujoaDi0sHz5+x8PjfsrjI600rQvV8XXx1KL29rGJYIQZWXhCzlcgd 2B+A1lh13P8pyUDC1YMVvnu1sUe1mh3IclWePCn1ypiQfRvZdijdvGdVpx12pqcI xUan5nQX6M2PrhlnBesVALTjG+sHRjdHxdzVls= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=SRrQDPSksVL Dse3n95kX/UTQ7KE=; b=ET2N0ibW+V+b8A6UfdG1KG6Editkb1iIaqKPI37t15e mCiLjmZVmHTsL5d+9pFOrkfktWmAyg48agqrjV5pIwBpVmC0cSmK5X0HU+hgFJsU QO6u7CTh8pinhUvZAdKlH4CTQo5nSs3Bc1qP79OkDZe35ZYTSQebJSsatIZN75dw = Received: (qmail 100010 invoked by alias); 21 Jan 2019 18:22:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 100001 invoked by uid 89); 21 Jan 2019 18:22:24 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: relay1.mentorg.com Date: Mon, 21 Jan 2019 18:22:16 +0000 From: Joseph Myers To: Zack Weinberg CC: , Carlos O'Donell , Florian Weimer , DJ Delorie , Arjun Shankar Subject: Re: [PATCH] Use a proper C tokenizer to implement the obsolete typedefs test. In-Reply-To: <20190119164627.14259-1-zackw@panix.com> Message-ID: References: <20190119164627.14259-1-zackw@panix.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1505175627-1548094936=:11564" ---1152306461-1505175627-1548094936=:11564 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Sat, 19 Jan 2019, Zack Weinberg wrote: > It is also feasible to make the new test understand the difference > between _defining_ the obsolete typedefs and _using_ the obsolete > typedefs, which means posix/{bits,sys}/types.h no longer need to be > exempted. This uncovered an actual bug in bits/types.h: __quad_t and > __u_quad_t were being used to define __S64_TYPE, __U64_TYPE, > __SQUAD_TYPE and __UQUAD_TYPE. These are changed to __int64_t and > __uint64_t respectively. (__SQUAD_TYPE and __UQUAD_TYPE should be > considered obsolete as well, but that is more of a change than I feel > is safe during the freeze. Note that the comments in bits/types.h > claiming a difference between *QUAD_TYPE and *64_TYPE were also in > error: supposedly QUAD_TYPE is ‘long long’ in all ABIs whereas 64_TYPE > is ‘long’ in LP64 ABIs, but that appears never to have been true; both > are defined as ‘long’ in LP64 ABIs. I made a minimal change to make > the comments not completely wrong and will revisit this whole area for > the next release.) Note that theoretically this could affect semantics (__int64_t is explicitly signed, __quad_t only implicitly so, so with -funsigned-bitfields __quad_t bit-fields would be unsigned but __int64_t bit-fields would always be signed). I think such a change is a good thing, and reasonably safe even at the present development stage (and generally typedefs that are implicitly signed should best be made explicitly signed to avoid such variations with -funsigned-bitfields), but it is still a possible semantic difference. This is not a review of the patch. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1505175627-1548094936=:11564--