All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	linux-hardening@vger.kernel.org,
	Daniel Latypov <dlatypov@google.com>,
	Vitor Massaru Iha <vitor@massaru.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] overflow: Allow mixed type arguments
Date: Wed, 31 Aug 2022 10:49:07 -0700	[thread overview]
Message-ID: <202208311040.C6CA8253@keescook> (raw)
In-Reply-To: <787894a0-b1b7-43c2-c509-f246f94f58f7@rasmusvillemoes.dk>

On Tue, Aug 30, 2022 at 09:52:32PM +0200, Rasmus Villemoes wrote:
> On 30/08/2022 21.21, Kees Cook wrote:
> > [...]
> > + * *@d holds the results of the attempted addition, but is not considered
> > + * "safe for use" on a non-zero return value, which indicates that the
> > + * sum has overflowed or been truncated.
> 
> I don't like that wording. It makes it sound like there's some ambiguity
> or (implementation|un)-definedness involved in what the destination
> holds on overflow. The gcc documentation is perfectly clear that the
> result is the infinite-precision result truncated to N bits, with N
> being the bitwidth of d.

Hm, well, I think use of *d should be strongly discouraged on overflow.
How about just adding the specifics to the end?

 * *@d holds the result of the attempted addition, but is not considered
 * "safe for use" on a non-zero return value, which indicates that the
 * sum has overflowed or been truncated. (*@d will contain the
 * infinite-precision result truncated to the bitwidth of *@d.)

-- 
Kees Cook

  reply	other threads:[~2022-08-31 17:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 19:21 [PATCH v3] overflow: Allow mixed type arguments Kees Cook
2022-08-30 19:34 ` Andrzej Hajda
2022-08-30 19:52 ` Rasmus Villemoes
2022-08-31 17:49   ` Kees Cook [this message]
2022-09-06 15:50 ` Gwan-gyeong Mun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202208311040.C6CA8253@keescook \
    --to=keescook@chromium.org \
    --cc=andrzej.hajda@intel.com \
    --cc=dlatypov@google.com \
    --cc=gustavoars@kernel.org \
    --cc=gwan-gyeong.mun@intel.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=ndesaulniers@google.com \
    --cc=vitor@massaru.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.