Date: Wed, 2 Nov 2011 14:21:59 -0400 From: John Baldwin <jhb@freebsd.org> To: Jilles Tjoelker <jilles@stack.nl> Cc: arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call Message-ID: <201111021421.59542.jhb@freebsd.org> In-Reply-To: <20111102181140.GA21621@stack.nl> References: <201110281426.00013.jhb@freebsd.org> <201110311024.07580.jhb@freebsd.org> <20111102181140.GA21621@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, November 02, 2011 2:11:41 pm Jilles Tjoelker wrote:
> On Mon, Oct 31, 2011 at 10:24:07AM -0400, John Baldwin wrote:
> > > The comparisons
>
> > > + (fa->fa_start != 0 && fa->fa_start == end + 1) ||
> > > + (uap->offset != 0 && fa->fa_end + 1 == uap->offset))) {
>
> > > should instead be something like
>
> > > + (end != OFF_MAX && fa->fa_start == end + 1) ||
> > > + (fa->fa_end != OFF_MAX && fa->fa_end + 1 == uap->offset))) {
>
> > > to avoid integer overflow.
>
> > Hmm, but the expressions will still work in that case, yes? I already
> > check for uap->offset and uap->len being negative earlier (so fa_start
> > and fa_end are always positive), and off_t is signed, so if end is
> > OFF_MAX, then end + 1 will certainly not == fa_start?
>
> Signed integer overflow is undefined behaviour; therefore, if you write
> end + 1 without checking that end != OFF_MAX, the compiler may assume
> that end != OFF_MAX. Whether the compiler will take advantage of this in
> ways that cause breakage is another question. For example, if there were
> a subsequent check for end != OFF_MAX, the compiler would be allowed to
> remove that check. I think it is best not to risk it.
Ok.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201111021421.59542.jhb>