Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Feb 2015 05:51:06 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        "Simon J. Gerraty" <sjg@juniper.net>
Cc:        Poul-Henning Kamp <phk@phk.freebsd.dk>, Anuranjan Shukla <anshukla@juniper.net>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject:   Re: Buggy sbspace() on 64bit builds?
Message-ID:  <20150207053557.L3468@besplex.bde.org>
In-Reply-To: <2705.1423240024@chaos>
References:  <D0F95E21.2489D%anshukla@juniper.net> <37282.1423208201@critter.freebsd.dk> <2705.1423240024@chaos>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Feb 2015, Simon J. Gerraty wrote:

> Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>>> Any thoughts on what a fix should be for this?
>>
>> size_t or intptr_t ?
>
> I don't think so, the bug lies in the fact that on 64bit long is much
> bigger than the uint's that are being manipulated.
> Using a result object the same size works.

Yes, using typedefed types just complicates the analysis, and size_t is
unsigned so using it tends to give the same (un)sign extension bugs as
using u_int.

Most variables should be plain int.  It is then implicit that the values
are not too large positive or negative for expressions involving them
to overflow.  The subtraction here is especially easy to understand.
Its terms must be nonnegative, so overflow can't happen.  Its terms
should also not be very large, but that is not needed here.

If variables have an unsigned type (except possibly u_char or u_short),
then everywhere that they are used the reader has to worry about them
actually needing to be unsigned for the purpose of holding very large
values or overflow not really being possible (it just gives the result
modulo 2**N).

The bug could also be fixed by changing everything to size_t.  On
64-bit arches, that would waste 32 bits for all the fields in the struct,
and it still needs delicate conversions to put differences in signed longs.
Using a consistently wide type does give a better chance of the delicate
conversions occurring accidentally.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150207053557.L3468>