220 40298 article Path: news.gmane.org!.POSTED!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: 128 bit integers Date: Wed, 3 Oct 2018 12:31:32 -0700 (PDT) Lines: 201 Approved: news@gmane.org Message-ID: References: <4111d349-b11d-45a4-aa06-d871d8efb20e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1524_2060408542.1538595092697" X-Trace: blaine.gmane.org 1538594970 26405 195.159.176.226 (3 Oct 2018 19:29:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 Oct 2018 19:29:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKLT4PURQHRBFNS2TOQKGQEAMI2YII@isocpp.org Wed Oct 03 21:29:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g7mpo-0006k2-TA for gclcip-std-proposals@m.gmane.org; Wed, 03 Oct 2018 21:29:25 +0200 Original-Received: by mail-yw1-f71.google.com with SMTP id n205-v6sf3740782ywc.16 for ; Wed, 03 Oct 2018 12:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=YIS4AkSUTfzhZUPNE7VrQx/tGMMisLkP0ozmcav0SS8=; b=0ilR1hOyOZC2wNYqNMdyRX2XrzYPR0FhsNi3gHyek1dzhTvuNr+zljOj9XT4VpfpYU A9bv5imWgHcpWAFy5MZ8CEKm1l3E1atAetfs/8P9tBru9IcIUOBEvklXaM8Vb2z8jKGu 3hysrJpfPla2QSVrnG2cvSSKnDtymkVwqeSfRmL7UAS47kghdvGOKUxSN8uAYuD5sMrr cLMeBXJrC9m/laqaVkPvoO5KBD8Vmo+RVk+4uuuEt1h4iZbgaHlwuWY060qQb9GWy3II OEqDBXkffDOBfEvnj7EP4/RXTYvaKpISKAu56PDQ4ShyBZNY44EW6+vyJiAcnXbUu/+0 tXbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=YIS4AkSUTfzhZUPNE7VrQx/tGMMisLkP0ozmcav0SS8=; b=tV1ovsjFokDGxptw1azI7DOaPQdt4igzywLKpypENIknkECQXUD0x/mVM1LLBdahrE v0y8IXYYoyvB3UCTyFSxEFswcgvVDhsk0nKUSBNop3XrfR1oejNxR4dEAfiH6+4r0Wk0 cRnVeMy5PDOYmO7dcj/L2uLgcjZ+Q3C4tf+U1emt5tVWa5wxO7JGQSM4/ITwOM+/fDMG TT9Z+uAlZgsQW2OG/Uwo90hJ+w5dkmQRQVyrdEY5DK7eckN4gHCFyH/pliajBakBTvxJ 2G5nbd7kgQqJQhbjkWJs+V7cCkwAUs0RT1F+Gi2pfkO05vUA/5kpNNGKWz653Mc7cYJ2 W7VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=YIS4AkSUTfzhZUPNE7VrQx/tGMMisLkP0ozmcav0SS8=; b=HfGk4BeSL+an1m/oiU6oocHaPWdRK8YK7xQeCQfsNsGgU6rhoeS7Hk6Lnr7wmsoZ7x ZuFTlaFbtlkHqTXXB7wzJmDA00I/eVZ0d7eB3aAR51Fie2ObTmrML2+J4ftOLWTkO1es yMV461QwQtUgH6NyNv7wZfiP7D4R7MvK4+EKrTyOdxpC/TkilfEhGxzbmAUIaox5+0Ar oaBh+2IKxlhJp/bitXmOMFXgqPhfQa2ZNo9omdJ0MatsCgAYB7SVPfeg9vsxTwiRcIiT zQWKBwAMm1+9e3awQRYRzHzne34F+GHFEbJG1k7miGAyJBBs+utXLpOg33ZLRak1T4UJ 542g== X-Gm-Message-State: ABuFfogFqzEnKfTySoSxEUVjqd4vQwyM6oDKGL3E16OV6xKinhHYjZlN 14wy4czhbHBE9Ja7GoueDFtOkw== X-Google-Smtp-Source: ACcGV60O+6eE0L4dKDuVuDGqdtQSKwiQ08O24FMKKFCzUfHSZ7HnChcLrDRz7Ifo7OzLSw38RTuntQ== X-Received: by 2002:a25:1a09:: with SMTP id a9-v6mr1536284yba.77.1538595095055; Wed, 03 Oct 2018 12:31:35 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:8706:: with SMTP id x6-v6ls807525ywf.10.gmail; Wed, 03 Oct 2018 12:31:33 -0700 (PDT) X-Received: by 2002:a81:1a07:: with SMTP id a7-v6mr46510ywa.1.1538595093378; Wed, 03 Oct 2018 12:31:33 -0700 (PDT) In-Reply-To: X-Original-Sender: myriachan@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40298 Archived-At: ------=_Part_1524_2060408542.1538595092697 Content-Type: multipart/alternative; boundary="----=_Part_1525_182893966.1538595092697" ------=_Part_1525_182893966.1538595092697 Content-Type: text/plain; charset="UTF-8" One issue with the current C++ Standard is that it does not allow cstdint to define anything other than 8/16/32/64/max, whereas the C Standard does. So an implementation cannot currently define a std::uint128_t but could define a uint128_t. The C Standard mentions the possibility of non-power-of-2 sizes, calling out uint24_t as an example. (Trivia: uint24_t would actually be a sensible type on an eZ80.) The C++ Standard ought to do the same as the C Standard. We also should get a proposal for std::uint_t and such. A separate problem with something like uint128_t is that it breaks the definition of uintmax_t. We can't change uintmax_t on an existing platform, because that's a breaking change. And if uint128_t exists and is larger than uintmax_t, what does that mean? Melissa On Wednesday, October 3, 2018 at 10:35:37 AM UTC-7, Brian Bi wrote: > > Why does it matter whether it's built-in? What would uint128_t do that > uint<128> wouldn't? > > Also can someone link me to the proposal that defines uint<128> and > friends? Thanks > > On Tue, Oct 2, 2018 at 3:09 AM Niall Douglas > wrote: > >> I just posted the following to the WG14 reflector, copying it here for >> some std-proposals extra feedback. >> >> Niall >> >> --- cut --- >> >> Dear WG14, >> >> As you may know, C++ is busy adding variable bit number support to itself >> (`int<128>`, `uint<256>` etc), but what I find myself yearning for is a >> simple, ordinary, builtin 128-bit signed and unsigned integer type which >> acts exactly like a normal integer, just bigger. >> >> 1. Would WG14 approve of adding builtin 128-bit signed and unsigned >> integer types to C22? If so, I can write the paper. >> >> 2. If so, what would be the preferred choice of naming? Some choices: >> >> a) Leaving the type unspecified, and instead say that `uint128_t` and >> `int128_t` will typedef to whatever it is. >> >> b) `unsigned long long long` and `long long long`. >> >> c) `_UInt128` and `_Int128`. >> >> >> In terms of prior art, GCC and clang already implement 128-bit integers ( >> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have done >> so for many years now. There is definitely an established user base, >> surprise ought to be very limited. >> >> Niall >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ISO C++ Standard - Future Proposals" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to std-proposal...@isocpp.org . >> To post to this group, send email to std-pr...@isocpp.org . >> To view this discussion on the web visit >> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-d871d8efb20e%40isocpp.org >> >> . >> > > > -- > *Brian Bi* > -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bb2c51f1-8fdf-4a94-8edb-8c4183b70968%40isocpp.org. ------=_Part_1525_182893966.1538595092697 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One issue with the current C++ Standard is that it do= es not allow cstdint to define anything other than 8/16/32/64/max, whereas = the C Standard does.=C2=A0 So an implementation cannot currently define a s= td::uint128_t but could define a uint128_t.

The C = Standard mentions the possibility of non-power-of-2 sizes, calling out uint= 24_t as an example.=C2=A0 (Trivia: uint24_t would actually be a sensible ty= pe on an eZ80.)

The C++ Standard ought to do t= he same as the C Standard.=C2=A0 We also should get a proposal for std::uin= t_t<N> and such.

A separate problem with som= ething like uint128_t is that it breaks the definition of uintmax_t.=C2=A0 = We can't change uintmax_t on an existing platform, because that's a= breaking change.=C2=A0 And if uint128_t exists and is larger than uintmax_= t, what does that mean?

Melissa

=
On Wednesday, October 3, 2018 at 10:35:37 AM UTC-7, Brian Bi wrote:
Why does it mat= ter whether it's built-in? What would uint128_t do that uint<128>= wouldn't?

Also can someone link me to the proposal = that defines uint<128> and friends? Thanks

On Tue, Oct 2, 2018 at 3:09 AM Niall Doug= las <nialldo...@gmail.com> wrote:
I just posted the following to the WG14 reflector, cop= ying it here for some std-proposals extra feedback.

Nial= l

--- cut ---

Dear WG1= 4,

As you may know, C++ is busy adding variable bi= t number support to itself (`int<128>`, `uint<256>` etc), but w= hat I find myself yearning for is a simple, ordinary, builtin 128-bit signe= d and unsigned integer type which acts exactly like a normal integer, just = bigger.

1. Would WG14 approve of adding builtin 12= 8-bit signed and unsigned integer types to C22? If so, I can write the pape= r.

2. If so, what would be the preferred choice of= naming? Some choices:

=C2=A0 a) Leaving the type = unspecified, and instead say that `uint128_t` and `int128_t` will typedef t= o whatever it is.

=C2=A0 b) `unsigned long long lo= ng` and `long long long`.

=C2=A0 c) `_UInt128` and= `_Int128`.


In terms of prior art, = GCC and clang already implement 128-bit integers (https://= gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html) and have do= ne so for many years now. There is definitely an established user base, sur= prise ought to be very limited.

Niall
<= div>

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com= /a/isocpp.org/d/msgid/std-proposals/4111d349-b11d-45a4-aa06-= d871d8efb20e%40isocpp.org.


--
Brian Bi=

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/bb2c51f1-8fdf-4a94-8edb-8c4183b70968= %40isocpp.org.
------=_Part_1525_182893966.1538595092697-- ------=_Part_1524_2060408542.1538595092697-- .