On 05/18/18 11:29, Ian Lepore wrote: > 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 > >
An excellent question all around. It appears that the maintainer at Qualcom acked the linux commit, so I'm not sure how to interpret all of this. sean
signature.asc
Description: OpenPGP digital signature
