220 33029 <7d74dcfa-358f-4fb9-8cc7-ffa854563952@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: Thu, 29 Jun 2017 09:41:27 -0700 (PDT) Lines: 104 Approved: news@gmane.org Message-ID: <7d74dcfa-358f-4fb9-8cc7-ffa854563952@isocpp.org> References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@isocpp.org> <4fcbc46d-7754-1061-4c67-22ef74756fd2@wanadoo.fr> <47af44a1-4895-44da-b9af-090c75b53c37@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3576_234751402.1498754487857" X-Trace: blaine.gmane.org 1498754491 16452 195.159.176.226 (29 Jun 2017 16:41:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 16:41:31 +0000 (UTC) Cc: federico.kircheis@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCZ3PBGHYEBBBOG32TFAKGQEI5SKDXQ@isocpp.org Thu Jun 29 18:41:27 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQcVQ-0003zN-VI for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 18:41:25 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id c190sf13746309ith.3 for ; Thu, 29 Jun 2017 09:41:30 -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=9Rkso8oFy+9rNGryprLSa7KLb+qY3DbKEXNZrqvIYZU=; b=Gqa3KSzspJCfbucH+JoI8ty+8Po80B+vgXdAH9MoVnZbtMKYwMnBKzf7MH8x+Um1kF SrB4G4o1TnvPy2ivevgurfKh6r9SOoiLLPUQddf7VV8GsVxBgo5mNn5gbWVfpBlgLhUu 2RmW3s48T77jbzP179Y4y5aomTYnok4hudd5MZJZLA6lfX5QFxT/qF0yq4s9M0Y9jTTI RHZF3/IHK67xZRks8xVTj3rckGt4znoDZZkde//bW+yPonEMCrKqz5Yte1sWYL1OUwzs w0z01h/ZKI7YCqrneOYeAk8elqhi53OEKJjK7RT41iWazivbTYFxg4QehsXXctElzjPf kiwQ== 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=9Rkso8oFy+9rNGryprLSa7KLb+qY3DbKEXNZrqvIYZU=; b=YgQUDSIM8el4mNeG49gB+piSTVv9rk//nEfYFal5n0ISVwWpuLGE8y7mTgubSzL7ut RoAW6/Wf37MvejPUHmGQoZhoSWfJnA5tQTB5soxqr7J1yBsx0FmoKucihLiFUcZHT80E b+QVdlCnAR2kH28b5BFRTtI9pk6xAq++kuTnb7ljdsyYiH7eC+8o74yM1a4zkjZEzIfw UI1WDsh5fChFRvSY/hEopF0iKHj5jeWzUz6BRpn+GJhdSSkIEieN2CwQGEXDfYdFGVgV 0iQHnmdtxL9QyUQ4Cq/fa6bWmvx4rfwKdb0d5UAvCFDwe+gdNVBNVz+YqCbODq1O4X1P 78Eg== 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=9Rkso8oFy+9rNGryprLSa7KLb+qY3DbKEXNZrqvIYZU=; b=kLeK0cwfTtJVsYZnI1YpvDf8NIODZfJBjlExRva4RoJflFCdn+zJn205mrfadcg0YP Hv64XQ0+niCYxSeUFQY36GIYb/m/X+x32VkLPiQYZKyUHCGszGbQJeai3izln92sd0dm nmToZ1c5b3EezG6o+L6podu86F6K48Q16LaOh2zFTMZ2Yl1xQuy5TWqENgbcHwpZPVku 7oWpsuLerlGfVjP48Ju6mMBmYihijJxw/AR6nfcvOF8s7Kf7U0K0ZkQjQCMok++MWaok jzIT8oNsMf7waO4QWRxwgzv8fyEcTOSkOloVsDxoZBEysSQUQq3jJDr2tU1nKwJeL64N YCJg== X-Gm-Message-State: AKS2vOxCvOV0g7dMTuMy1QRHqr2deIirbhomu7IN/sE/AuJxvt3OsEYD CFMcrFb3V/hhZYuK X-Received: by 10.36.50.210 with SMTP id j201mr7820137ita.35.1498754489895; Thu, 29 Jun 2017 09:41:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.25.133 with SMTP id b127ls4461319itb.10.canary-gmail; Thu, 29 Jun 2017 09:41:28 -0700 (PDT) X-Received: by 10.36.16.207 with SMTP id 198mr119486ity.1.1498754488430; Thu, 29 Jun 2017 09:41:28 -0700 (PDT) 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:33029 Archived-At: ------=_Part_3576_234751402.1498754487857 Content-Type: multipart/alternative; boundary="----=_Part_3577_1888084006.1498754487857" ------=_Part_3577_1888084006.1498754487857 Content-Type: text/plain; charset="UTF-8" > If you have for example a hash routine, with an update function, which > length parameter is an int and not a size_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__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.? > > I'm a little bit lost. Could you elaborate? > > It was just an example that came to my mind where you do not want a narrow_cast but a less_cmp operation, suppose you have the function signature: void update(hash_type t, unsigned char* tohash, int len) but most of the time you have the length expressed in terms of size_t. You might therefore write something like void my_update(hash_type t, unsigned char* tohash, std::size_t len){ auto intmax = std::numeric_limits::max(); while(cmp_less(intmax, len)){ update(t, tohash, intmax) len -= intmax; tohash +=intmax } update(t, tohash, len) } whereas narrow_casting directly "size_t len" to "int len", would just hide the problem since in this case, you know how to deal with the overflow (which may not be true in most cases). -- 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/7d74dcfa-358f-4fb9-8cc7-ffa854563952%40isocpp.org. ------=_Part_3577_1888084006.1498754487857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If you have for example a hash routine, with an update function, which length parameter is an int and not a size_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.?
I'm a little bit lost. Could you elaborate?

It was just an example that came to my mind where you do not want a= narrow_cast but a less_cmp operation, suppose you have the function signat= ure:

void update(hash_type t, unsigned char* tohash, int len)
but most of the time you have the length expressed in terms of size_t. You= might therefore write something like
=C2=A0
void my_update(hash_type= t, unsigned char* tohash, std::size_t len){
=C2=A0=C2=A0 auto intmax = =3D std::numeric_limits<int>::max();
=C2=A0=C2=A0 while(cmp_less(i= ntmax, len)){
=C2=A0=C2=A0=C2=A0=C2=A0 update(t, tohash, intmax)
=C2= =A0=C2=A0=C2=A0=C2=A0 len -=3D intmax;
=C2=A0=C2=A0=C2=A0=C2=A0 tohash += =3Dintmax
=C2=A0=C2=A0 }
=C2=A0=C2=A0 update(t, tohash, len)
}
whereas narrow_casting directly "size_t len" to "int le= n", would just hide the problem since in this case, you know how to de= al with the overflow (which may not be true in most cases).

--
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/7d74dcfa-358f-4fb9-8cc7-ffa854563952= %40isocpp.org.
------=_Part_3577_1888084006.1498754487857-- ------=_Part_3576_234751402.1498754487857-- .