svn commit: r300332 - in head/sys: amd64/amd64 i386/i386

[Conrad Meyer]

On Fri, May 20, 2016 at 6:10 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Fri, 20 May 2016, Conrad Meyer wrote:
>
>> On Fri, May 20, 2016 at 4:02 PM, Bruce Evans <brde at 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