220 30784 <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@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: Mon, 6 Feb 2017 09:23:56 -0800 (PST) Lines: 103 Approved: news@gmane.org Message-ID: <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@isocpp.org> References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1635_1008569127.1486401836450" X-Trace: blaine.gmane.org 1486401843 32066 195.159.176.226 (6 Feb 2017 17:24:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 17:24:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ3PBGHYEBBBLPC4LCAKGQED5A5LSY@isocpp.org Mon Feb 06 18:23:54 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1can16-0007uI-SD for gclcip-std-proposals@m.gmane.org; Mon, 06 Feb 2017 18:23:53 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id a88sf44274586uaa.1 for ; Mon, 06 Feb 2017 09:23:58 -0800 (PST) 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6Hdq05SI++nU4uZINTYL6j2T69ZaOZ8PF+oIxVAqSLA=; b=j+0PPAM0knu8KaQiWoBrYSR6BMFXD7+oJyTyXjWIaqg+IwonQgkaB++YYo8QNh+QSc t4QfYFOa1Ei32pXxpilBwJzqe/6Ced2pxBammAaYSBYfv872V6rrRLtKXuDY1WvTlqPk mi5YnwN8g0qTmLrL2Ksp+KCkPlI/26hcaW4SYAUUkNQzk9e7VY4+3mju6/FXCpRpqo1b FLAdzEi389SlkK9VeDOJrVrpyrivIYq/2lS7FwAPAJfZe+xAi02TVwRHmLBh3dvJQ2WP A41mHDejNnJOyYvLzQppjDRVV7qUkr7YP6CQfkA7djPxFMefCA4iHi/v2vNxjTumRcOQ ZbNw== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=6Hdq05SI++nU4uZINTYL6j2T69ZaOZ8PF+oIxVAqSLA=; b=dqShEA3LyBl4NaoSR0bOoi+1W5/Lu5Qar26exA9TGH/OJum0BiscrZGZqxP5y3MA5T yFcMEuTXICvV3QF+JJWrb/SmksLeOeLCl/Zclux5I9Nk+tq3wk91lT2I5AhkWuSJwzFO +vC5+7tnHT8MuVYw5Zm3Ajj1EMX8GgV/svbyMrQuybP1N5lSlJEz5xBy574pHyNh+srl VFwHAa5DeK7J2nyMW4c/dwU8R3+sq9m2VVJfJwAHWLlw/9ED4pO96kVGH7LxeHzWCLox 5kuI57c7Tpem+s6j1i8kDM5eNVWZJpvkt3PEJlUxOguYK2NvucrhK5xs4Ee6iXDda+Oz tfEw== 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=6Hdq05SI++nU4uZINTYL6j2T69ZaOZ8PF+oIxVAqSLA=; b=lNN2uqpaYfMX/QrjnTqnOZNa4FsmHi44iu9pcS/splWuNp/1Tbiy1nlM85AIPE8O3U vh1q2IMY7EFnOSf//0/Qvi0PLXEl/Xyu56quRx1Ju5hbsDPfrLHGKjmJbyydXJGzSRCt rM79MfBLYnR9lGoVnsn4po6YPzkU5FnsoLB/nJRNxYscfdmWVhLkmMUVnLUlpM84BvTs YcUMHBqf/1zSAtp4FmWNKNAAtxxYEiRxBeQBka7pBr2EZm093BFesC3+lk04ASR7LTkd IXtw3ZU/Krs42f4zO7OrBgHqgDM4CkuFD3uSSWpcHBnhZ4HON/7jiPSmtaQx2e9EWY++ Pizw== X-Gm-Message-State: AMke39kTJ5xiKTxCbD1hiAo9ge+d3lsp4Z1rRz1dp5Ty0LUNovRCQk7zhID/1V9v69WxDg== X-Received: by 10.159.37.36 with SMTP id 33mr1694438uaz.13.1486401837844; Mon, 06 Feb 2017 09:23:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.42.46 with SMTP id t43ls14759792ota.17.gmail; Mon, 06 Feb 2017 09:23:57 -0800 (PST) X-Received: by 10.157.35.89 with SMTP id k25mr573251otd.11.1486401836994; Mon, 06 Feb 2017 09:23:56 -0800 (PST) In-Reply-To: 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:30784 Archived-At: ------=_Part_1635_1008569127.1486401836450 Content-Type: multipart/alternative; boundary="----=_Part_1636_1841719393.1486401836450" ------=_Part_1636_1841719393.1486401836450 Content-Type: text/plain; charset=UTF-8 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". 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 cannot find any reference to the operator <=> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0100r2.html), do you have a link? 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). 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. 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/6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b%40isocpp.org. ------=_Part_1636_1841719393.1486401836450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Vicente,

thank you for your feedback.

I w= as not aware of narrow/narrow cast.
If they do provide the same function= ality and it's going to be in the next std release, then I could drop t= he proposal for "in_range".

One possible issue is that you= may not know, between two types, which is the bigger one (for example insi= de a templated function). So a function like "can_be_narrowed" do= es not seem right because you are not going to narrow, whereas "in_ran= ge" does not have that issue -> seems more generic to me.

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?
<= br>I would gladly drop the function "precision", but if you are c= omparing 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).

If you are comparing an uint_8t w= ith 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 p= recise they are.
Normally I would use the sizeof operator to determine w= hich 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 impl= ementation detail), and can be removed from the proposal too, even if it se= ems to me a nice addition.


--
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/6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b= %40isocpp.org.
------=_Part_1636_1841719393.1486401836450-- ------=_Part_1635_1008569127.1486401836450-- .