Date: Wed, 14 Feb 2018 16:20:21 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Ian Lepore <ian@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r329237 - head/sys/libkern Message-ID: <20180214160048.E1450@besplex.bde.org> In-Reply-To: <1518551679.72050.4.camel@freebsd.org> References: <201802131917.w1DJHmso047463@repo.freebsd.org> <1518549829.85310.39.camel@freebsd.org> <CAPyFy2Cckiz8iBzy664-%2BpVCPJhmxdD_JmzmEpSo5WFV-b8DEA@mail.gmail.com> <1518551679.72050.4.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Feb 2018, Ian Lepore wrote: > On Tue, 2018-02-13 at 14:43 -0500, Ed Maste wrote: >> On 13 February 2018 at 14:23, Ian Lepore <ian@freebsd.org> wrote: >>> >>> On Tue, 2018-02-13 at 19:17 +0000, Ed Maste wrote: >>>> >>>> Author: emaste >>>> Date: Tue Feb 13 19:17:48 2018 >>>> New Revision: 329237 >>>> URL: https://svnweb.freebsd.org/changeset/base/329237 >>>> >>>> Log: >>>> =A0 libkern: use nul for terminating char rather than 0 >>>> >>>> =A0 Akin to the change made in r188080 for lib/libc/string/. >>>> >>>> =A0 Reported by:=A0=A0=A0=A0=A0=A0=A0=A0bde >>>> =A0 Sponsored by:=A0=A0=A0=A0=A0=A0=A0The FreeBSD Foundation >>> There are many ways to spell 0.=A0=A0Why are we using something other >>> than >>> the simplest way?=A0=A0Is it a style rule thing, or is it portability- >>> correctness, or what? style(9) requires '\0' (by always spelling the character constant with value 0 like that). >> I made the change to improve consistency between lib/libc/string and >> sys/libkern, which is what Bruce commented on some time ago. I don't >> have a personal preference for 0 or '\0' but definitely believe that >> if we have multiple, similar copies of a function they ought to avoid >> gratuitous differences. (I'm happy to change both trees to 0 if >> that's >> preferred.) Core parts of libc like stdio and (MI) string use '\0' fairly consistently. There were about 10-20 plain 0's in string in FreeBSD-5, but most of these have been changed to '\0'. This gives a much larger set of examples of normal style. > Oh, I agree completely about consistancy being important. =A0I just > wanted to know whether I should try to remember to always use \0 > because it's a rule or has some benefit I didn't know about. > > 20+ years ago I used to slavishly ensure I always used \0 when a char > type was involved, just as a personal style thing. =A0Then over time I > came to the conclusion that "0 is 0 no matter how you spell it, so keep > it simple" (except for pointers... even in c++ I've always used NULL). Probably the BSD style rule has the same origin. Bruce From owner-svn-src-head@freebsd.org Wed Feb 14 07:59:31 2018 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32341F09902; Wed, 14 Feb 2018 07:59:31 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D278F697F9; Wed, 14 Feb 2018 07:59:30 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id CCF725021; Wed, 14 Feb 2018 07:59:30 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w1E7xU9m027315; Wed, 14 Feb 2018 07:59:30 GMT (envelope-from eadler@FreeBSD.org) Received: (from eadler@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w1E7xUCH027314; Wed, 14 Feb 2018 07:59:30 GMT (envelope-from eadler@FreeBSD.org) Message-Id: <201802140759.w1E7xUCH027314@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: eadler set sender to eadler@FreeBSD.org using -f From: Eitan Adler <eadler@FreeBSD.org> Date: Wed, 14 Feb 2018 07:59:30 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r329259 - head/lib/msun/src X-SVN-Group: head X-SVN-Commit-Author: eadler X-SVN-Commit-Paths: head/lib/msun/src X-SVN-Commit-Revision: 329259 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 14 Feb 2018 07:59:31 -0000 Author: eadler Date: Wed Feb 14 07:59:30 2018 New Revision: 329259 URL: https://svnweb.freebsd.org/changeset/base/329259 Log: msun: signed overflow in atan2 As a component of atan2(y, x), the case of x == 1.0 is farmed out to atan(y). The current implementation of this comparison is vulnerable to signed integer underflow (that is, undefined behavior), and it's performed in a somewhat more complicated way than it need be. Change it to not be quite so cute, rather directly comparing the high/low bits of x to the specific IEEE-754 bit pattern that encodes 1.0. Note that while there are three different e_atan* files in the relevant directory, only this one needs fixing. e_atan2f.c already compares against the full bit pattern encoding 1.0f, while e_atan2l.cuses bitwise-ands/ors/nots and so doesn't require a change. Closes #130 Submitted by: Jeff Walden (@jswalden github PR #130) Reviewed by: bde MFC After: 1 month Modified: head/lib/msun/src/e_atan2.c Modified: head/lib/msun/src/e_atan2.c ============================================================================== --- head/lib/msun/src/e_atan2.c Wed Feb 14 02:51:28 2018 (r329258) +++ head/lib/msun/src/e_atan2.c Wed Feb 14 07:59:30 2018 (r329259) @@ -71,7 +71,7 @@ __ieee754_atan2(double y, double x) if(((ix|((lx|-lx)>>31))>0x7ff00000)|| ((iy|((ly|-ly)>>31))>0x7ff00000)) /* x or y is NaN */ return x+y; - if((hx-0x3ff00000|lx)==0) return atan(y); /* x=1.0 */ + if(hx==0x3ff00000&&lx==0) return atan(y); /* x=1.0 */ m = ((hy>>31)&1)|((hx>>30)&2); /* 2*sign(x)+sign(y) */ /* when y = 0 */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180214160048.E1450>