From owner-svn-src-head@freebsd.org Fri May 18 17:29:12 2018 Return-Path: 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 A8BAFEAF41F for ; Fri, 18 May 2018 17:29:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FA168056B for ; Fri, 18 May 2018 17:29:11 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f56ecea7-5ac0-11e8-9855-9df12b06b3a9 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id f56ecea7-5ac0-11e8-9855-9df12b06b3a9; Fri, 18 May 2018 17:29:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w4IHT3lh087166; Fri, 18 May 2018 11:29:03 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1526664543.32688.57.camel@freebsd.org> Subject: Re: svn commit: r333801 - head/sys/contrib/dev/ath/ath_hal/ar9300 From: Ian Lepore To: Sean Bruno , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Fri, 18 May 2018 11:29:03 -0600 In-Reply-To: <201805181723.w4IHNN6Y091949@repo.freebsd.org> References: <201805181723.w4IHNN6Y091949@repo.freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 17:29:12 -0000 On Fri, 2018-05-18 at 17:23 +0000, Sean Bruno wrote: > Author: sbruno > Date: Fri May 18 17:23:23 2018 > New Revision: 333801 > URL: https://svnweb.freebsd.org/changeset/base/333801 > > Log: >   Quiesce a couple pages of clang warnings with a cast.  Duplicates >   linux maintainer commit: >    >   https://github.com/torvalds/linux/commit/627871b71c89a6ec12fbed75063f238e0c7127b2#diff-8c6ddb4c3ad69a6fb9f289475821db56 >    >   ar9300template_aphrodite.h:575:40: warning: implicit conversion from 'int' >     to 'u_int8_t' (aka 'unsigned char') changes value from 3495 to 167 >     [-Wconstant-conversion] >               /* Data[8].ctl_edges[7].bChannel*/FREQ2FBIN(5795, 0)} >                                                 ^~~~~~~~~~~~~~~~~~ >   ar9300eep.h:142:41: note: expanded from macro 'FREQ2FBIN' >       (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) >    >   Reviewed by: imp >   MFC after: 1 week >   Differential Revision: https://reviews.freebsd.org/D15476 > > Modified: >   head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h > > Modified: head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h > ============================================================================== > --- head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h Fri May 18 17:07:59 2018 (r333800) > +++ head/sys/contrib/dev/ath/ath_hal/ar9300/ar9300eep.h Fri May 18 17:23:23 2018 (r333801) > @@ -139,7 +139,7 @@ enum Ar9300EepromTemplate >  #define OSPREY_CUSTOMER_DATA_SIZE    20 >   >  #define FREQ2FBIN(x,y) \ > -    (((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) > +    (u_int8_t)(((y) == HAL_FREQ_BAND_2GHZ) ? ((x) - 2300) : (((x) - 4800) / 5)) >  #define FBIN2FREQ(x,y) \ >      (((y) == HAL_FREQ_BAND_2GHZ) ? (2300 + x) : (4800 + 5 * x)) >  #define OSPREY_MAX_CHAINS            3 > How can this change possibly be correct? All the values involved are compile-time constants, the compiler did the math and tells you the result is 3495. Cast or not, that value is never going to fit into a uint8_t. Sure this supresses the warning, but what about actually fixing the overflow? -- Ian