I don't think we need redefinitions of TRUE/FALSE Ron's argument against using BIT(16) makes sense to me.
I don't have a problem with BIT16, 0x10000, or (1 << 16) but #define VENDOR_BIT_16 0x10000 seems like overkill. I'd really generally prefer some good definitions though instead of write(BIT16) I'd really like to see: #define ENABLE_FEATURE BIT16 write(ENABLE_FEATURE) I know that at times we don't have good documentation about what the values actually do, but we've got a lot of magic numbers throughout our code. How would people feel about adding something to the coding guide to avoid magic numbers? Martin On Thu, Feb 4, 2016 at 6:05 AM, ron minnich <rminn...@gmail.com> wrote: > > > On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot > <coreboot@coreboot.org> wrote: >> >> >> >> 1. TRUE/FALSE >> Do we want such defines? If so, TRUE/FALSE, or true/false, or >> True/False, or ...? > > > should we start using bool ...? >> >> >> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x10000 >> I don't think it makes sense to go for a single one of these (0x3ff is >> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8 >> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both >> BIT16 and BIT(16). >> > > BIT16 is a constant. BIT(16) is a chance for things to go badly wrong, e.g. > BIT(x-y) might produce some very strange problems. I kind of prefer the > constant. > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot