From owner-svn-src-all@freebsd.org Sat May 21 04:13:50 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46FDAB4432C; Sat, 21 May 2016 04:13:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id C48C31E87; Sat, 21 May 2016 04:13:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-149-109.carlnfd1.nsw.optusnet.com.au (c122-106-149-109.carlnfd1.nsw.optusnet.com.au [122.106.149.109]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id F252E78175F; Sat, 21 May 2016 14:13:46 +1000 (AEST) Date: Sat, 21 May 2016 14:13:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Conrad Meyer cc: Bruce Evans , Konstantin Belousov , 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 In-Reply-To: Message-ID: <20160521123908.V1914@besplex.bde.org> References: <201605201950.u4KJoWA5028092@repo.freebsd.org> <20160521081930.I1098@besplex.bde.org> <20160521103528.I1539@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=c+ZWOkJl c=1 sm=1 tr=0 a=R/f3m204ZbWUO/0rwPSMPw==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=FTh5clMInHnvHWAiyd4A:9 a=gQ_H6biWQVUu4wsx:21 a=wLGhfzaGJq1eDdCj:21 a=CjuIK1q_8ugA:10 a=Oa0T6EYmKFNB-xRHvYM1:22 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 04:13:50 -0000 On Fri, 20 May 2016, Conrad Meyer wrote: > On Fri, May 20, 2016 at 6:10 PM, Bruce Evans wrote: >> On Fri, 20 May 2016, Conrad Meyer wrote: >> >>> On Fri, May 20, 2016 at 4:02 PM, Bruce Evans 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