Date: Sat, 21 May 2016 14:13:44 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Conrad Meyer <cem@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Konstantin Belousov <kib@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r300332 - in head/sys: amd64/amd64 i386/i386 Message-ID: <20160521123908.V1914@besplex.bde.org> In-Reply-To: <CAG6CVpXoTxFyo_-mD5NfpUEHJmxrrry6Nnw-Hr5mR0z2_JzHrQ@mail.gmail.com> References: <201605201950.u4KJoWA5028092@repo.freebsd.org> <20160521081930.I1098@besplex.bde.org> <CAG6CVpUtz49L0VWfPcCXFvEMiV41AwxhJ8tGjenLqgPJt_kpyA@mail.gmail.com> <20160521103528.I1539@besplex.bde.org> <CAG6CVpXoTxFyo_-mD5NfpUEHJmxrrry6Nnw-Hr5mR0z2_JzHrQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 May 2016, Conrad Meyer wrote:
> On Fri, May 20, 2016 at 6:10 PM, Bruce Evans <brde@optusnet.com.au> wrote:
>> On Fri, 20 May 2016, Conrad Meyer wrote:
>>
>>> On Fri, May 20, 2016 at 4:02 PM, Bruce Evans <brde@optusnet.com.au> wrote:
>>>>
>>>> On Fri, 20 May 2016, Konstantin Belousov wrote:
>>>>
>>>>> --- head/sys/i386/i386/sys_machdep.c Fri May 20 19:46:25 2016
>>>>> (r300331)
>>>>> +++ head/sys/i386/i386/sys_machdep.c Fri May 20 19:50:32 2016
>>>>> (r300332)
>>>>> @@ -315,8 +315,9 @@ i386_set_ioperm(td, uap)
>>>>> struct thread *td;
>>>>> struct i386_ioperm_args *uap;
>>>>> {
>>>>> - int i, error;
>>>>> char *iomap;
>>>>> + u_int i;
>>>>> + int error;
>>>>>
>>>>> if ((error = priv_check(td, PRIV_IO)) != 0)
>>>>> return (error);
>>>>> @@ -334,7 +335,8 @@ i386_set_ioperm(td, uap)
>>>>> return (error);
>>>>> iomap = (char *)td->td_pcb->pcb_ext->ext_iomap;
>>>>>
>>>>> - if (uap->start + uap->length > IOPAGES * PAGE_SIZE * NBBY)
>>>>> + if (uap->start > uap->start + uap->length ||
>>>>> + uap->start + uap->length > IOPAGES * PAGE_SIZE * NBBY)
>>>>> return (EINVAL);
>>>>>
>>>>> for (i = uap->start; i < uap->start + uap->length; i++) {
>>>>
>>>>
>>>> I don't like using u_int for a small index.
>>>
>>>
>>> Why not? Indices are by definition non-negative so the fit seems natural.
>>
>> Signed integers are easier to understand provided calculations with them
>> don't overflow.
>
> How?
For the same reasons as in applying mathematics. Applying mathematics
was harder before negative numbers were invented. Negative numbers
are actually not easy to understand at the technical level (the usual
representation of them is equivalence classes of pairs of non-negative
numbers), but their properties are easy to understand and work with
once you are familiar with them and don't think about their
implementation details too much.
Ordinary (real) numbers (including negative ones) also have good ordering
properties for all operations.
Computer arithmetic can't represent all ordinary numbers, but gets closest
by representing ordinary integers as C signed integers perfectly when no
overflow occurs.
By using C unsigned integers unnecessarily, you throw out invention of
negative numbers and might have to work with the unfamiliar and badly
behaved ordering on them. C programmers have some experience with this
ordering, but apparently not enough to usually avoid bugs.
> The rest of the argument seems to be, using u_int is bad because more
> unsigned is always bad. But I haven't seen a good reason to believe
> that is so.
Not always bad. Sometimes you must use C unsigned integers to get a full
representation without wasting many bits, or actually want the ordering
of unsigned integers. The main case is representing other C things like
pointers. Differences of pointers are still hard to handle.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160521123908.V1914>