220 33012 <47af44a1-4895-44da-b9af-090c75b53c37@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: federico.kircheis@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: safe integrals comparison Date: Wed, 28 Jun 2017 22:10:13 -0700 (PDT) Lines: 424 Approved: news@gmane.org Message-ID: <47af44a1-4895-44da-b9af-090c75b53c37@isocpp.org> References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@isocpp.org> <4fcbc46d-7754-1061-4c67-22ef74756fd2@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3259_1335460591.1498713013342" X-Trace: blaine.gmane.org 1498713018 14226 195.159.176.226 (29 Jun 2017 05:10:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 05:10:18 +0000 (UTC) Cc: federico.kircheis@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ3PBGHYEBBBNUX2LFAKGQELO3YREI@isocpp.org Thu Jun 29 07:10:13 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb0-f200.google.com ([209.85.213.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQRiU-0003Jy-Rf for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 07:10:11 +0200 Original-Received: by mail-yb0-f200.google.com with SMTP id g206sf59943543yba.3 for ; Wed, 28 Jun 2017 22:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=DPjLYDCvt2vqia3f5RGbo9t0xffRfzstgFUMp2eiD2A=; b=YkMshh8LrcNExQFgsZ23eZO0Nlq7BpAfL27cSGzfK984oDQLrIoGA+K8JOGGBnopSS 6DhwNKxZ9T4a/444C85wIdQg5wRT7dqNVmBTdvw6WhsQrGhdBxwd/eqz09kTWYZ1AEFJ o5B6J7dp9BT3BdT1/rPGjjBvZBfrcARywSerm4nLvgAxiq3oeVSVxJJVgIBv5OJWpWF3 3LLMjbjtAblUymhHZepqj0BhKQIs/XivTMAN6NrmV28OlBWTo+DpPybPMh4c/F4KAPPL L9sRwHlRPQfI3U4QDuYsHGyVE1sDQG70aG3PwopBdeTHMZvlK0KOC5ZfFvQi8nGzyMbV 4trw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=DPjLYDCvt2vqia3f5RGbo9t0xffRfzstgFUMp2eiD2A=; b=Gry434c9Ej8PYmHiaVa/7LBlpNlt7ytQlJx9zWn3erYt/4IfKBtkdfd2EZoY5ZVU6I gLcZoaZ0uwW5ZRfU/ieecmv48taAhPmMp6EbRBsRNBje93tU8wAiQRN2jZzZ1gMpvm/s VDioaHAgRTIE0qn0xghdlTvQyRmxbSIY/wvskRaEmBydfCjU8qpVfzlq9PlU8ZT3RZyF EtcyWZdvbWhz24z2PTflkcyQ8ZqnY/Zcu2jb2tWqx0W+qloim+leId+UjYm1HrC2xPZe 2DMTbeX8JR/neYuysnfgCZP6YtsLLl8U9WV2Sy4wFxyVVL0h7VHTj76sm3PEOQSRUl9O R5eQ== 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:cc: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=DPjLYDCvt2vqia3f5RGbo9t0xffRfzstgFUMp2eiD2A=; b=Th40W1uat5/V78tsE6aZGhDooQYfDIzcunevNFHE1rysrYGjUzZ59adFDT7Pp0R7aB Ay/q/8XEcwizgJA6vesH5WW3HvWqu9nBxvYTNa59JQViRVM6hoDrKZrOaNpIEYW5rPq1 6VsDLPXMnIEPDbH8aWD42XJ50y8A1TYc1rfQrm8S6/OPEcgD8azK0pd+X+FafAb2uwDg 9zsQ63g2U8sWHz+z5NHqQ4PS5CViLmDuTw9kPkk7SoL1WMMuck2VRkzW06XOxBGoJtSW l7rCleZ9SOuBBIfQ3DPcqznrcAgY2DmW0XCaMm8L5LobjLD31C1UodHWQzIh8ZPVtruF OIUQ== X-Gm-Message-State: AKS2vOzYF05WI9SS4JdYdUAHTORXZ5eEgpvcuu3Ccqfc2DFTA5TJY4yE XsHRwUwkuOGIPe0M X-Received: by 10.129.159.145 with SMTP id w139mr9153774ywg.132.1498713015731; Wed, 28 Jun 2017 22:10:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.25.133 with SMTP id b127ls3513467itb.10.canary-gmail; Wed, 28 Jun 2017 22:10:14 -0700 (PDT) X-Received: by 10.36.79.144 with SMTP id c138mr15647itb.2.1498713013974; Wed, 28 Jun 2017 22:10:13 -0700 (PDT) In-Reply-To: <4fcbc46d-7754-1061-4c67-22ef74756fd2@wanadoo.fr> X-Original-Sender: federico.kircheis@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:33012 Archived-At: ------=_Part_3259_1335460591.1498713013342 Content-Type: multipart/alternative; boundary="----=_Part_3260_1643007177.1498713013342" ------=_Part_3260_1643007177.1498713013342 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, One possible issue is that you may not know, between two types, which is=20 > the bigger one (for example inside a templated function). So a function= =20 > like "can_be_narrowed" does not seem right because you are not going to= =20 > narrow, whereas "in_range" does not have that issue -> seems more generic= =20 > to me. > > I don't see the difference. You can use narrow when the type is a subset= =20 > of the other. The implementation could be specialized to just return true= =20 > in this case? > It's more a naming issue, but nothing. With narrowing you expect to get s= =20 smaller type, that's all. I wan't to stress that narrow_cast alone is not enough, we should have,=20 like you have called it, a can_be_narrowed. IMHO narrow_cast should throw. I'm not against throwing, but it makes=20 little sense if you already know how to handle that error, for example=20 splitting you operation in multiple steps. If you have for example a hash routine, with an update function, which=20 length parameter is an int and not a size_t(happened to me moer than once),= =20 you can write your wrapper that takes the size_t, and if the value is=20 bigger than numeri_limits__max() split the operation in multiple=20 updates. If you are casting immediately, you have to write less clear code IMHO.=20 Therefore we should really have a function for checking the relative=20 position of different integers.? > I cannot find any reference to the operator <=3D> ( > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0100r2.html), do= =20 > you have a link? > > Sorry it was=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf > > Looks very interesting, I have mixed feelings about another operator for= =20 comparing value, but that behaves differently (even if in a more sensible= =20 way) with native types. Is there some active discussion about it? If we would have such an=20 operator, most of the functions I'm proposing will be unnecessary. I'ill=20 add a reference, thank you. > I would gladly drop the function "precision", but if you are comparing an= =20 > unsigned type with a signed type, and both variables contains a positive= =20 > value(!), how do you know if you need to cast them both to signed or to= =20 > unsigned? If you do the comparison with std::numeric_limits without=20 > casting, an implicit conversion could give you an unexpected result (that= s=20 > the whole point of this proposal). > > My concern was to define a trait instead of a constexpr function, but=20 > maybe we are going to constexpr functions now. > I've implemented it as a constexpr function, since I find it a lot easier= =20 to reason about it and use it (like I said, I'm not a template master), of= =20 course it can also be implemented as a trait, maybe I should mention it.=20 =20 Il giorno mercoled=C3=AC 28 giugno 2017 22:35:13 UTC+2, Vicente J. Botet Es= criba=20 ha scritto: > > Le 06/02/2017 =C3=A0 18:23, federico...@gmail.com a= =20 > =C3=A9crit : > > Hi Vicente, > > thank you for your feedback. > > I was not aware of narrow/narrow cast. > If they do provide the same functionality and it's going to be in the nex= t=20 > std release, then I could drop the proposal for "in_range". > > There is not a current proposal, but I would like it on the standard. > > > One possible issue is that you may not know, between two types, which is= =20 > the bigger one (for example inside a templated function). So a function= =20 > like "can_be_narrowed" does not seem right because you are not going to= =20 > narrow, whereas "in_range" does not have that issue -> seems more generic= =20 > to me. > > I don't see the difference. You can use narrow when the type is a subset= =20 > of the other. The implementation could be specialized to just return true= =20 > in this case? > > I cannot find any reference to the operator <=3D> ( > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0100r2.html), do= =20 > you have a link? > > Sorry it was=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf > > > I would gladly drop the function "precision", but if you are comparing an= =20 > unsigned type with a signed type, and both variables contains a positive= =20 > value(!), how do you know if you need to cast them both to signed or to= =20 > unsigned? If you do the comparison with std::numeric_limits without=20 > casting, an implicit conversion could give you an unexpected result (that= s=20 > the whole point of this proposal). > > My concern was to define a trait instead of a constexpr function, but=20 > maybe we are going to constexpr functions now. > > Best, > Vicente > > > If you are comparing an uint_8t with an int_32t, you should cast to=20 > int_32t since it can contain all values of uint_8t, but if you are=20 > comparing and uint_16t with an int_16 you should cast to uint_16t, since = it=20 > can contain all positive values of int_16t. > So it depends on how big the "range" of the types are, i.e. how precise= =20 > they are. > Normally I would use the sizeof operator to determine which of both types= =20 > is more precise, but as stated in securecoding, padding bits may be an=20 > issue. So why not provide this function to the end user as a bonus? Of=20 > course this function is not strictly necessary (it's an implementation=20 > detail), and can be removed from the proposal too, even if it seems to me= a=20 > nice addition. > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to std-proposal...@isocpp.org . > To post to this group, send email to std-pr...@isocpp.org=20 > . > To view this discussion on the web visit=20 > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6a3e0be1-3a7= a-4cfd-a4a9-d49cd72bb52b%40isocpp.org=20 > > . > > > --=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/47af44a1-4895-44da-b9af-090c75b53c37%40isocpp.or= g. ------=_Part_3260_1643007177.1498713013342 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

One possible issue is that you may not know, between two types, which is the bigger one (for example inside a templated function). So a function like "can_be_narrowed" does not = seem right because you are not going to narrow, whereas "in_range&q= uot; does not have that issue -> seems more generic to me.

I don't see the difference. You can use narrow when the type is a subset of the other. The implementation could be specialized to just return true in this case?

It's more = a naming issue, but nothing. With narrowing you expect to get s smaller typ= e, that's all.
I wan't to stress that narrow_cast alone is not e= nough, we should have, like you have called it, a can_be_narrowed.
IMHO = narrow_cast should throw. I'm not against throwing, but it makes little= sense if you already know how to handle that error, for example splitting = you operation in multiple steps.

If you have for example a hash rout= ine, with an update function, which length parameter is an int and not a si= ze_t(happened to me moer than once), you can write your wrapper that takes = the size_t, and if the value is bigger than numeri_limits<int>__max()= split the operation in multiple updates.
If you are casting immediately= , you have to write less clear code IMHO. Therefore we should really have a= function for checking the relative position of different integers.?
<= blockquote type=3D"cite">
I cannot find any reference to the operator <=3D> (http://www.open-std.org/j= tc1/sc22/wg21/docs/papers/2016/p0100r2.html), do you have a link?
Sorry it was http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf

Looks very interesting, I have mixed feelin= gs about another operator for comparing value, but that behaves differently= (even if in a more sensible way) with native types.
Is there some activ= e discussion about it? If we would have such an operator, most of the funct= ions I'm proposing will be unnecessary. I'ill add a reference, than= k you.



I would gladly drop the function "precision", but if you = are comparing an unsigned type with a signed type, and both variables contains a positive value(!), how do you know if you need to cast them both to signed or to unsigned? If you do the comparison with std::numeric_limits without casting, an implicit conversion could give you an unexpected result (thats the whole point of this proposal).
My concern was to define a trait instead of a constexpr function, but maybe we are going to constexpr functions now.

I've implemented it as a constexpr function, since I find it= a lot easier to reason about it and use it (like I said, I'm not a tem= plate master), of course it can also be implemented as a trait, maybe I sho= uld mention it.
=C2=A0Il giorno mercoled=C3=AC 28 giugno 20= 17 22:35:13 UTC+2, Vicente J. Botet Escriba ha scritto:
=20 =20 =20
Le 06/02/2017 =C3=A0 18:23, federico...@gmail.com a =C3=A9crit=C2=A0:
Hi Vicente,

thank you for your feedback.

I was not aware of narrow/narrow cast.
If they do provide the same functionality and it's going to be in the next std release, then I could drop the proposal for "in_range".
There is not a current proposal, but I would like it on the standard.

One possible issue is that you may not know, between two types, which is the bigger one (for example inside a templated function). So a function like "can_be_narrowed" does not = seem right because you are not going to narrow, whereas "in_range&q= uot; does not have that issue -> seems more generic to me.

I don't see the difference. You can use narrow when the type is a subset of the other. The implementation could be specialized to just return true in this case?
I cannot find any reference to the operator <=3D> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0100= r2.html), do you have a link?
Sorry it was http://= www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf<= br>

I would gladly drop the function "precision", but if you = are comparing an unsigned type with a signed type, and both variables contains a positive value(!), how do you know if you need to cast them both to signed or to unsigned? If you do the comparison with std::numeric_limits without casting, an implicit conversion could give you an unexpected result (thats the whole point of this proposal).
My concern was to define a trait instead of a constexpr function, but maybe we are going to constexpr functions now.

Best,
Vicente

If you are comparing an uint_8t with an int_32t, you should cast to int_32t since it can contain all values of uint_8t, but if you are comparing and uint_16t with an int_16 you should cast to uint_16t, since it can contain all positive values of int_16t.
So it depends on how big the "range" of the types are, i.= e. how precise they are.
Normally I would use the sizeof operator to determine which of both types is more precise, but as stated in securecoding, padding bits may be an issue. So why not provide this function to the end user as a bonus? Of course this function is not strictly necessary (it's an implementation detail), and can be removed from the proposal too, even if it seems to me a nice addition.


--
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.goog= le.com/a/isocpp.org/d/msgid/std-proposals/6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b%40isocpp.org.


--
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/47af44a1-4895-44da-b9af-090c75b53c37= %40isocpp.org.
------=_Part_3260_1643007177.1498713013342-- ------=_Part_3259_1335460591.1498713013342-- .