From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5534 invoked by alias); 30 Oct 2013 22:51:27 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5517 invoked by uid 89); 30 Oct 2013 22:51:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2013 22:51:21 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1Vbebc-0002Pw-Sv from joseph_myers@mentor.com ; Wed, 30 Oct 2013 15:51:16 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Oct 2013 15:51:16 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Wed, 30 Oct 2013 22:51:14 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VbebZ-0008VD-EH; Wed, 30 Oct 2013 22:51:13 +0000 Date: Wed, 30 Oct 2013 22:51:00 -0000 From: "Joseph S. Myers" To: DJ Delorie CC: Subject: Re: proposal to make SIZE_TYPE more flexible In-Reply-To: <201310302219.r9UMJg9e001309@greed.delorie.com> Message-ID: References: <201310300422.r9U4M6Mx002568@greed.delorie.com> <201310301917.r9UJHxg7028662@greed.delorie.com> <201310302219.r9UMJg9e001309@greed.delorie.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-10/txt/msg00323.txt.bz2 On Wed, 30 Oct 2013, DJ Delorie wrote: > So, given all that, is there any way to add the "target-specific > size_t" portion without waiting for-who-knows-how-long for the intN_t > and enum-size-type projects to finish? Some form of interim API that > we can put in, so that we can start working on finding all the > assumptions about size_t, while waiting for the rest to finish? I have no idea how ugly something supporting target-specific strings would be, since supporting such strings for these standard typedefs never seemed to be a direction we wanted to go in. (Obviously it's possible to convert only a subset of macros to use enums rather than strings, or to be hooks rather than macros.) -- Joseph S. Myers joseph@codesourcery.com