From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92132 invoked by alias); 27 Aug 2015 09:32:35 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 92120 invoked by uid 89); 27 Aug 2015 09:32:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f170.google.com Received: from mail-yk0-f170.google.com (HELO mail-yk0-f170.google.com) (209.85.160.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 27 Aug 2015 09:32:33 +0000 Received: by ykdt205 with SMTP id t205so13823230ykd.1 for ; Thu, 27 Aug 2015 02:32:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.51.140 with SMTP id z134mr426591ywz.36.1440667951952; Thu, 27 Aug 2015 02:32:31 -0700 (PDT) Received: by 10.37.214.136 with HTTP; Thu, 27 Aug 2015 02:32:31 -0700 (PDT) In-Reply-To: <55DEB83C.5010106@westcontrol.com> References: <1B1111BE-E274-4C80-8189-22B78D77647A@gmail.com> <55DDAD64.3040607@westcontrol.com> <55DDE30A.1080506@gmail.com> <55DEB83C.5010106@westcontrol.com> Date: Thu, 27 Aug 2015 09:32:00 -0000 Message-ID: Subject: Re: 128-bit integer - nonsensical documentation? From: Jonathan Wakely To: David Brown Cc: Martin Sebor , Kostas Savvidis , gcc-help Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00191.txt.bz2 On 27 August 2015 at 08:11, David Brown wrote: > Is that allowed even if __int128 is not an "extended integer"? I can > see why gcc would not want to make __int128 an extended integer, if it > then causes knock-on effects such as changing intmax_t. But if the > standards allow for literals of type __int128 even if it is not defined > as an extended integer, then that might be a nice feature to make the > type more complete and consistent. If the literal used a syntax that is not valid in ISO C then it would be a valid extension, because its existence would not affect valid ISO C programs that don't use it. > Are you allowed to include typedefs for uint128_t and int128_t in > , or would that also only be allowed if it is a proper > extended integer? Those names are not in the namespace reserved for the implementation, so doing that would cause this valid code to fail to compile: #include typedef struct { } uint128_t; int main() { }