220 32984 <4fcbc46d-7754-1061-4c67-22ef74756fd2@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: safe integrals comparison Date: Wed, 28 Jun 2017 22:35:09 +0200 Lines: 219 Approved: news@gmane.org Message-ID: <4fcbc46d-7754-1061-4c67-22ef74756fd2@wanadoo.fr> References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------49D1469227ABCCDB0820DEBF" X-Trace: blaine.gmane.org 1498682116 5247 195.159.176.226 (28 Jun 2017 20:35:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Jun 2017 20:35:16 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 To: std-proposals@isocpp.org, federico.kircheis@gmail.com Original-X-From: std-proposals+bncBDH67CONY4PBB75F2DFAKGQE5CGBSVI@isocpp.org Wed Jun 28 22:35:12 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f71.google.com ([209.85.215.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQJg3-0000vc-Ko for gclcip-std-proposals@m.gmane.org; Wed, 28 Jun 2017 22:35:07 +0200 Original-Received: by mail-lf0-f71.google.com with SMTP id w198sf14821862lff.14 for ; Wed, 28 Jun 2017 13:35:13 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1498682113; cv=pass; d=google.com; s=arc-20160816; b=KWVxAf3TMMAXRB8sYZaY0si4tK6I9+iu458T1bwT1RJwMl6mddWeuwzh+kYPfwbW8Y TX3Eq/gwc2EnWccS4I64kY/oVaxLhiflGPxl/U2iPqeqAlllLm+LrjUaX70lkanZFjcD WRLH9UbovvsLwCbtYQNx0gj/TErwx91z07NmzCBAqnpgOvYdpdjxjTuyqNRBk9rhHSwl lXtrCGq8Ij5HGZIU1pUcB/eMGWPFEzAUoGVcSY5vv3+tgvPoAB2iuRQTduvXR2ebybiA qd/0+hdfEIhl3rbKMJ7g8yAVcA70Gi/r7eyCOd937Mo3VVknygX3MZUB/ZeAk6ElIkUR eLaA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=9AvkOCGpgi4tyQetHkFWWy4lq99Z/LXC77jPt88BMN8=; b=aMDv75AyFt6Jh6XqROGSJWj8LtxPC2/sPB9A3cyu+4v3BN58og5stDVvcrusn69Xm/ 6G2SmtZynO5ED4Ze960hZMc7uXqCyPexlfLjR45W2TrSWgcc4jO8oCgJpIxXRlGTk7gf FnkdS0ew8kBswdvYAVkiBdx06E8XM2xoiQcgIiiwG8YWkwzLD5XrZ55Mztbwleh9zxC2 SrmwplYdsSazfwNlFK1/CShSo4CV06XZQ8KI/iC5+l1aQ5q+T21xRwA9w8A9/FL/EwI2 bRy8naveKf15XUp5WtmAFeBRPFfyBYD8NZY33dIchoQYWuGi98gTe/kdu/P4cM4jaSRb ZT7A== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=9AvkOCGpgi4tyQetHkFWWy4lq99Z/LXC77jPt88BMN8=; b=H4OQoo0MnUH2pjsiGlRRSPrm856ubHQUSyjk+Pk0XyKGwZp59wc4NbZEDQlaO7eQIl vZCbM8XXC9RJyrqQ77n6sY3CB6DfxrwJOEhpycA76b/ms49RShsRUN+t6aRpYfxwp0qK 4wwM1LaMRuPV46v8CiFCq+F6mPt452A7SljeYxL+6r5Yaaws7c+WZmUaTaF4LzKKq4dI +3jFIpGey/Ne4Dj++iiuHf+yyVm+tXlPyjXroCIk1Euksr/K7TWq+LPx5OFUwk9ELBXV 16KfGJw2BdbGsSzPzYOUwibeA8Zqk4JE8LZta5uNfS8bqxiIjYbvxiIOnY0LfkFV8YYr QtPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :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=9AvkOCGpgi4tyQetHkFWWy4lq99Z/LXC77jPt88BMN8=; b=FKQpNZsKCnXeeDJCbCLuXMthmFqzaUIVBV0gXYxnrjEoSmUZNTjXtA6wa0VMoWA8uG bbcjSNUiXQ3NSTaWAcKJ+ejQExxWaj5BZhIyvqaigpoHJYZLFv/KYNcYEaqOkqCE/MED Qb1Dw4npAgIy+SiDSVgUGGtj1YtIyNB8ArKIYP/WZxHyHX8TKRdBsSHoeDa+qe02lFqb nyOuVyzrIgDU4e6Qo60oWnrFozPdOHWmEyYgvxnwaCiR/MADijIBPKXxtqUcL/sUsOT3 e28vP6W53kXHCdJG+iWDXS+RLL2mCpWFQJ+78E5mcCK2AdEUdbvAhDopfiqnorxJ6hF5 m X-Gm-Message-State: AKS2vOy6ewzBsJBCs/5NBj8U0by+Gww/grAGbuSgYZr/0WE1YjP0WqH7 JiR+fTlmJehsjA== X-Received: by 10.46.71.81 with SMTP id u78mr2365581lja.25.1498682113162; Wed, 28 Jun 2017 13:35:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.145.69 with SMTP id t66ls1034655wmd.12.canary-gmail; Wed, 28 Jun 2017 13:35:11 -0700 (PDT) X-Received: by 10.28.21.202 with SMTP id 193mr7831348wmv.99.1498682111347; Wed, 28 Jun 2017 13:35:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498682111; cv=none; d=google.com; s=arc-20160816; b=siD5hDtjlJ/izUNnsgoUOEU2QnEVYgu87miDhSTlB0DmBahUorBPf1BDNdzWhcQ+S4 b6biOSLItIh6Obk/r7FqApkID1Shh+wuqHkj7xDFb09aKq7oyystn8YsMgrY/+G5e82c hBqiSQ49abnMFexmmkLU/tvh76ahUuzLWK4RUaZncL6evdYXHyiZdxBqBPhgsJVpgBDj WsPI2kHqu5uUxahTKvzhgrpkpkVXKgpT6Ru9JOKFeETT6iidR2XguyQ4UEoNcVDxWddc mtHnYZwDdpGdmuFSvJ0TjaEw8z61kY7+8IUJBxE/7U3bnQQfiTRl/9sT65GsddEH0Vkg YveA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=U1qSEdUptlFB2cQRlVn1p1qnhizy00zZwD/CUGOEypE=; b=ciMf4PDUGY/znJNX+ElzcfvxG6E3vrOaD3URXTqFoFfd9Yk8S49OwH9ZMg9CLtgkrw WPa+HpWHOlKUyPoy5ywxCyTPuHLF7IVKDo1W3wIqZGu6VyIMcrqLGJcafMRZ3ZaQOh+6 6P1hgBwkGBKgZLKl9eBEJaFfzEADpIMB++84JTSFrbitrSCm303XLZlVVf0cDaxdA34h tHCyqFiYqup2ugtpJtgpJt6+ubPvRTyRE9zWz2/ILzzMv3sfPS7ZtoKZUxbtfNgpAxp0 jBCV8Cj6skZm0KRVbiix+Vfk92nUVqYUTiv8koYSXOqpplaFyiQPXtzLCF5LiqGBLhm8 ogEQ== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Original-Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr. [80.12.242.124]) by mx.google.com with ESMTPS id y45si2405332wrd.301.2017.06.28.13.35.11 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Jun 2017 13:35:11 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.124; Original-Received: from imac-de-vicente-botet-escriba.home ([81.53.30.137]) by mwinf5d25 with ME id eLb91v00P2xWGC103LbAit; Wed, 28 Jun 2017 22:35:11 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Wed, 28 Jun 2017 22:35:11 +0200 X-ME-IP: 81.53.30.137 In-Reply-To: <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@isocpp.org> Content-Language: en-US X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:32984 Archived-At: This is a multi-part message in MIME format. --------------49D1469227ABCCDB0820DEBF Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Le 06/02/2017 =C3=A0 18:23, federico.kircheis@gmail.com a =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=20 > 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=20 > is the bigger one (for example inside a templated function). So a=20 > function like "can_be_narrowed" does not seem right because you are=20 > not going to narrow, whereas "in_range" does not have that issue ->=20 > seems more generic 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=20 true in this case? > I cannot find any reference to the operator <=3D>=20 > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0100r2.html),= =20 > do 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=20 > an unsigned type with a signed type, and both variables contains a=20 > positive value(!), how do you know if you need to cast them both to=20 > signed or to unsigned? If you do the comparison with=20 > std::numeric_limits without casting, an implicit conversion could give=20 > you an unexpected result (thats 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,=20 > 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=20 > precise they are. > Normally I would use the sizeof operator to determine which of both=20 > types is more precise, but as stated in securecoding, padding bits may=20 > be an issue. So why not provide this function to the end user as a=20 > bonus? Of course this function is not strictly necessary (it's an=20 > implementation detail), and can be removed from the proposal too, even=20 > if it seems to me a nice addition. > > > --=20 > You received this message because you are subscribed to the Google=20 > Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to std-proposals+unsubscribe@isocpp.org=20 > . > To post to this group, send email to std-proposals@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/4fcbc46d-7754-1061-4c67-22ef74756fd2%40wanadoo.f= r. --------------49D1469227ABCCDB0820DEBF Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le 06/02/2017 =C3=A0 18:23, federico.kircheis@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" 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/p0100r2.html), do you have a link?
Sorry it was 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 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-proposals+unsubscribe@isocpp.org.<= br> To post to this group, send email to s= td-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/m= sgid/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/4fcbc46d-7754-1061-4c67-22ef74756fd2= %40wanadoo.fr.
--------------49D1469227ABCCDB0820DEBF-- .