From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E35BC4363D for ; Fri, 2 Oct 2020 08:10:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CDE75206B7 for ; Fri, 2 Oct 2020 08:10:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Mz1gYZ2M" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726017AbgJBIKI (ORCPT ); Fri, 2 Oct 2020 04:10:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52694 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725993AbgJBIKI (ORCPT ); Fri, 2 Oct 2020 04:10:08 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12D74C0613D0 for ; Fri, 2 Oct 2020 01:10:08 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id k10so735495wru.6 for ; Fri, 02 Oct 2020 01:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6saKikvunIQTzy9VDa8ect9p8mNJs0urWp3gRQrdgIE=; b=Mz1gYZ2Mwa3u0OC1RPVkHx+inF7f9uRvH2jI6JLnFD3bLNv5cY+dDYcDyWeh+B5yGM yn2K+wBVOqFlyxfLgaJcRrZQQcfD36PyJFw13P/4uWZ8VOsZ1TXZmiwHcvc8G6y0EpW9 cd28t6RO276Ax0vpqA23cIkWP2PtCadL+JR7YAgPkKULTGwfLI8/lsk+0NPwUKiAeI3/ /toD+hs495CuIK1InbIsz2vjq7y8KtOIz9wM8YuRsOgpm3eynqbOLjPRhQwVQyPlaZ5S l5z4hx5z18hn3wFhEAmDJ7l5xecknPb7OG20amcT110ZXF5Pm4z2D9C4FeY0eyWTYIoQ r0dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6saKikvunIQTzy9VDa8ect9p8mNJs0urWp3gRQrdgIE=; b=XG8IVVdrzEonCJYakls/NzvMAc6ybbV3qoM0389CjmYjDiYyC+lsUDztWLA+tMLtdc h1TkPcPSr/gziwU+rIzcYkwsGh1YXB0QTYEWsTFyiTkxpKJPEBlPRgxaQWB6OB+DAjVU Bp8HNgpM9UMctJuV52iltfSPea1jJ3dCXqXqLrIgQgRJnMktMQEc+LeaJVMko/TyKzeE oybO59JUrv1eFnuSezQIOPTvf4DBBqqbR7v0hfndlU2TwtcL+PrFTYoeGu4oRhE+z8zv T53z7Y1FMYC4UkyjXC1C4XeY5s7zJWEY5u3VyptCim2rclq3RZLBNtnyd7NOrrTVm364 uoHw== X-Gm-Message-State: AOAM533ik79A1XnSAdYoxFo8sik1+RkUglmvrBzhF1tVMWCqBe8hUXLY ByFabpIYXd6s+Bsq2Uh0MMg= X-Google-Smtp-Source: ABdhPJw83aaqW7Yfk1b2jV78TmD789hbiTKe1QfM2NCOQZCvf4+5ml6EBJVpsuKNXFGtvOorUrVtqA== X-Received: by 2002:adf:eacb:: with SMTP id o11mr1526026wrn.209.1601626206675; Fri, 02 Oct 2020 01:10:06 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id y14sm800110wma.48.2020.10.02.01.10.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 01:10:05 -0700 (PDT) Subject: Re: [RFC] man7/system_data_types.7: Document [unsigned] __int128 To: Joseph Myers Cc: Jonathan Wakely , "gcc@gcc.gnu.org" , linux-man , "Michael Kerrisk (man-pages)" References: <5ed7272e-1c81-d1f5-6a54-0fee4270199e@gmail.com> From: Alejandro Colomar Message-ID: <5e12ffdb-4b7b-0720-98a1-3c111acff6ae@gmail.com> Date: Fri, 2 Oct 2020 10:10:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On 2020-10-01 15:46, Jonathan Wakely wrote: > I hope WG14 will adopt something like > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2465.pdf and the > whole mess will go away. > > intmax_t will be deprecated, and implementations can provide 128-bit > integers without caveats. On 2020-10-01 19:31, Joseph Myers wrote: > On Thu, 1 Oct 2020, Alejandro Colomar via Gcc wrote: > >> Because 'intmax_t' has a bug >> (actually I know GCC rejected the bug report, >> but the problem is still there and users should be informed about this) >> which is related to __int128. > > __int128 is not an integer type as defined by any existing version of ISO > C, precisely because it's wider than intmax_t, and changing intmax_t would > be a big ABI problem (involving new symbol versions for about 100 > printf/scanf-related functions in glibc, 200 on platforms with multiple > long double variants). > > See the proposed removal of intmax_t in C2x (accepted in principle at the > first virtual Freiburg meeting, but so far without any wording accepted > for any specific approach to removal regarding e.g. preprocessor > arithmetic and other places depending on intmax_t). That removal would > allow __int128 to be considered an extended integer type as defined by C2x > and later (with int128_t typedef in , etc.), if desired. > Thanks for pointing out that the standard acknowledges the bug in [u]intmax_t. It's good to know. Also good to know they plan to fix it. Thanks, Alex