Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 May 2016 18:54:41 -0700
From:      Conrad Meyer <cem@FreeBSD.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        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:  <CAG6CVpXoTxFyo_-mD5NfpUEHJmxrrry6Nnw-Hr5mR0z2_JzHrQ@mail.gmail.com>
In-Reply-To: <20160521103528.I1539@besplex.bde.org>
References:  <201605201950.u4KJoWA5028092@repo.freebsd.org> <20160521081930.I1098@besplex.bde.org> <CAG6CVpUtz49L0VWfPcCXFvEMiV41AwxhJ8tGjenLqgPJt_kpyA@mail.gmail.com> <20160521103528.I1539@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

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.

> Unsigned integers are not easier to understand if
> calculations with them do overflow.  That was the case here.
>
> Only indices relative to the base of an array are by definition
> non-negative.  For an array a[], it is valid to do p = &a[i] and then
> use p[j] with negative j to get back before the i'th index.  This is
> sometimes useful.  i + j must be >= 0, but is hard write correctly and
> understand if either i or j is unsigned.  (It can be arranged that the
> addition wraps correctly, but this is basically re-implementing signed
> arithmetic.)

This has devolved from an array and index, to pointer arithmetic.  The
fact that C lets you do pointer arithmetic with array syntax doesn't
help.  The "real" indices are always non-negative.

Best,
Conrad



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