[coreboot] RFC: coding style: "standard" defines
gaumless at gmail.com
Thu Feb 4 22:22:07 CET 2016
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
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
How would people feel about adding something to the coding guide to
avoid magic numbers?
On Thu, Feb 4, 2016 at 6:05 AM, ron minnich <rminnich at gmail.com> wrote:
> On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot
> <coreboot at 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
> coreboot mailing list: coreboot at coreboot.org
More information about the coreboot