220 28966 article Path: news.gmane.org!.POSTED!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: uint16_t data =x= static_cast(1) + 1; Date: Wed, 19 Oct 2016 09:31:42 -0300 Lines: 213 Approved: news@gmane.org Message-ID: References: <47e7f79f-8676-4a63-b7d3-09d64219d575@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c0bf85e1da557053f36fee3 X-Trace: blaine.gmane.org 1476880341 9777 195.159.176.226 (19 Oct 2016 12:32:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2016 12:32:21 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBBNGPTXAAKGQEZNLXLZA@isocpp.org Wed Oct 19 14:32:16 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f198.google.com ([209.85.161.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwq2A-0006m9-4a for gclcip-std-proposals@m.gmane.org; Wed, 19 Oct 2016 14:31:50 +0200 Original-Received: by mail-yw0-f198.google.com with SMTP id t192sf45113657ywf.4 for ; Wed, 19 Oct 2016 05:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=KBH6nVNmcnznWNiEOz63L+Z1aLQ+A+LI52uCVld434A=; b=pQOsUUV/XFtVYJYt76JAYt88aE6rNhp3EeWMPg6a04hanDmL3ES+by7wOcwQB/MQ/X /GciEt6++DV4JoaxpStJaB9n3F3h0zi77gUDEAL+l9UDqYIXUkQR/57XzcX69DZE+Uop IgwRGU0ncbCRyXGmO+IOUYWRjj8T1gbzApxjZ93UX8Wh+rxdoWp5ZDcHBBoojCa6xCTI vIKUyXPvRIzlk2Yg7edKtVAp4Brpdd+gTrdEnAgy8eOl15zmDUK6LqPgYoEfnOmC0DX+ EcxWdOL01/qOBN0YBvw4ChvZWSQCiRQRl5jvcZEHmYZmeccKWEjb+xXdXMdFC+wgFPib y0LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KBH6nVNmcnznWNiEOz63L+Z1aLQ+A+LI52uCVld434A=; b=QACdNKz/pVXB0tO+pVGIq4SPYlkfmyjgbDD+dbF/WUdypfFX0f+FBN+ck6O7iq2nWH 2/eHL4gmj3tIo4UL3LGt2LB1viz4larjXzcdnjAaEn7BwX32FC14DSBjkHU0+aGLP9Cm ZOuUyaOtB/kjCeyI4EvZ2gohYJeyZIxmMk28Cb4KrzPTEUA02uVz9FQEJMW+wKuZmWx2 KVbnm5K9lxGd8lXY2rJVZLkbGn8M70Naq6bZq2qx/QZNpJjV7iOzXr7h4Y2zthdw1cM8 sYJeScwT+e2r1AZ/1lz+rm6uYMt6xReGFpvby+D6nUHmXu6pogKmwgSuNtS0k6Rg3I/O fnPw== X-Gm-Message-State: AA6/9RkZxID33foHFxdFLtGspuO5pPol1y2KLsD9eaBKVCJ8w2140lSrX/+d2wVsa9CT5A== X-Received: by 10.13.251.134 with SMTP id l128mr1572953ywf.159.1476880309363; Wed, 19 Oct 2016 05:31:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.54.164 with SMTP id h33ls1691560otc.12.gmail; Wed, 19 Oct 2016 05:31:48 -0700 (PDT) X-Received: by 10.237.58.38 with SMTP id n35mr5921190qte.45.1476880308597; Wed, 19 Oct 2016 05:31:48 -0700 (PDT) Original-Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com. [2607:f8b0:400d:c09::234]) by mx.google.com with ESMTPS id d12si24164581qtc.70.2016.10.19.05.31.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 05:31:48 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400d:c09::234 as permitted sender) client-ip=2607:f8b0:400d:c09::234; Original-Received: by mail-qk0-x234.google.com with SMTP id f128so31521631qkb.1 for ; Wed, 19 Oct 2016 05:31:48 -0700 (PDT) X-Received: by 10.233.235.85 with SMTP id b82mr6233754qkg.156.1476880307683; Wed, 19 Oct 2016 05:31:47 -0700 (PDT) Original-Received: by 10.36.86.145 with HTTP; Wed, 19 Oct 2016 05:31:42 -0700 (PDT) In-Reply-To: <47e7f79f-8676-4a63-b7d3-09d64219d575@isocpp.org> X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400d:c09::234 as permitted sender) smtp.mailfrom=danielgutson@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:28966 Archived-At: --94eb2c0bf85e1da557053f36fee3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 18, 2016 at 8:11 PM, wrote: > Writing a hypervisor in C++, and at least on Intel that are a lot of > things that require 8 and 16 bit integers. To my surprise, this generates= a > warning about conversions: > > uint16_t data1 =3D 1; > uint16_t data2 =3D data1 + 1; // warning on possible overflow > Interestingly, g++ (5.4) does not complain with that snippet, until you do { } initialization: uint16_t data1{1}; uint16_t data2{data1 + 1}; ....then: warning: narrowing conversion of =E2=80=98(((int)data1) + 1)=E2=80=99 from = =E2=80=98int=E2=80=99 to =E2=80=98uint16_t {aka short unsigned int}=E2=80=99 inside { } [-Wnarrowing= ] uint16_t data2{data1 + 1}; ^ Are you using g++ as well? I'm thinking about patching gcc about this. I can't get rid off the warning even by explicitly casting the 1 to uint16_t. I think that a type promotion due to performance reasons should be considered differently that one explicitly performed, in the way that it should be immediately demoted to the original type. Different is the case of a multiplication. I'm thinking out loud from the compiler maintainer point of view. IOW, I think the compiler could do: constexpr uint16_t add_u16(uint16_t x, uint16_t y) { return uint16_t(uint32_t(x) + uint32_t(y)); } in this very case, as a QoI thing. > > The reason is, in C++, when you perform arithmetic, the compiler is > allowed to up-cast for you to an int if it results in a performance > improvement. So the compiler changes the result of data1 + 1 to an int, a= nd > then complains because you could lose data if you store an int back into > something smaller, even though the programmer never intended it to be an > int in the first place. The following also fails which gets rid of the 1 > which is technically an int (although no warnings are fired when you stor= e > 1 into something smaller.. only when you use it in arithmetic): > > uint16_t data1 =3D 1; > uint16_t data2 =3D 1; > uint16_t data3 =3D data1 + data2; // warning on possible overflow > > Now... one might think.. that warning is valid because adding 1 to > anything could result in an overflow, except that the same is not true fo= r > an int. > > int data1 =3D 1; > int data2 =3D 1; > int data3 =3D data1 + data2; // compiles fine > > Has there ever been a proposal to fix this? At least in our code, this on= e > fix would get rid of a LOT of gsl::narrow_casts as it seems to me the > warning is a bit overkill as the programmer's intent is valid, it's the > compiler doing wonky things. > > Thanks a ton, > - Rian > > -- > 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/47e7f79f-8676-4a63- > b7d3-09d64219d575%40isocpp.org > > . > --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --=20 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 e= mail 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/CAFdMc-1RPatYOmggBx%3D_4uHTMo1hei9npMhXcmyo4VA0m= uT0gg%40mail.gmail.com. --94eb2c0bf85e1da557053f36fee3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 18, 2016 at 8:11 PM, <rianquinn@gmail.com> wrote:
Writing a hypervisor in C++, and at least on Intel that are a lot = of things that require 8 and 16 bit integers. To my surprise, this generate= s a warning about conversions:

uint16_t data1 =3D = 1;
uint16_t data2 =3D data1 + 1; =C2=A0// warning on possible ove= rflow

Interestingly, g++ (5= ..4) does not complain with that snippet, until you do { } initialization:uint16_t data1{1};
uint16_t data2{data1 + 1};

...the= n:

warning: narrowing conversion of =E2=80=98(((int)data1) + 1)=E2= =80=99 from =E2=80=98int=E2=80=99 to =E2=80=98uint16_t {aka short unsigned = int}=E2=80=99 inside { } [-Wnarrowing]
=C2=A0uint16_t data2{data1 + 1};<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 ^
Are you using g++ as well? I'm think= ing about patching gcc about this. I can't get rid off the warning even= by explicitly casting the 1 to uint16_t.

I th= ink that a type promotion due to performance reasons should be considered d= ifferently that one explicitly performed, in the way that it should be imme= diately demoted to the original type. Different is the case of a multiplica= tion.
I'm thinking out loud from the compiler maintainer = point of view.
IOW, I think the compiler could do:
<= div>constexpr uint16_t add_u16(uint16_t x, uint16_t y)
{
= =C2=A0=C2=A0=C2=A0 return uint16_t(uint32_t(x) + uint32_t(y));
}
in this very case, as a QoI thing.

=C2=A0

The reason is, in C++, when you pe= rform arithmetic, the compiler is allowed to up-cast for you to an int if i= t results in a performance improvement. So the compiler changes the result = of data1 + 1 to an int, and then complains because you could lose data if y= ou store an int back into something smaller, even though the programmer nev= er intended it to be an int in the first place. The following also fails wh= ich gets rid of the 1 which is technically an int (although no warnings are= fired when you store 1 into something smaller.. only when you use it in ar= ithmetic):

uint16_t data1 =3D 1;
uint16_t= data2 =3D 1;
uint16_t data3 =3D data1 + data2; // warning on pos= sible overflow

Now... one might thi= nk.. that warning is valid because adding 1 to anything could result in an = overflow, except that the same is not true for an int.=C2=A0

=
int data1 =3D 1;
int data2 =3D 1;
int data3 = =3D data1 + data2; // compiles fine

Has = there ever been a proposal to fix this? At least in our code, this one fix = would get rid of a LOT of gsl::narrow_casts as it seems to me the warning i= s a bit overkill as the programmer's intent is valid, it's the comp= iler doing wonky things. =C2=A0

Thanks a ton,
- Rian

--
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-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/47e7= f79f-8676-4a63-b7d3-09d64219d575%40isocpp.org.



--
Who=E2=80=99s got the sweetest disposition?
One gu= ess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?Who never shows a bit of temperament?
Who's never wrong but always = right?
Who'd never dream of starting a fight?
Who get stuck with = all the bad luck?

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFdMc-1RPatYOm= ggBx%3D_4uHTMo1hei9npMhXcmyo4VA0muT0gg%40mail.gmail.com.
--94eb2c0bf85e1da557053f36fee3-- .