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>