[coreboot] RFC: coding style: "standard" defines

[Alex G.]

Hi there,

This seems pretty simple.

On 02/04/2016 01:35 AM, Patrick Georgi via coreboot wrote:
> Hi all,
> 
> during the review of some commits that are in the process of being
> upstreamed from Chrome OS, people noticed that chipset drivers like to
> define their own TRUE/FALSE defines (sometimes prefixed to), and I
> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
> be the house rules in some firmware communities.
> 
> I think we should seek uniformity here: decide on some style,
> recommend it, clean up the tree to match, and help people stay
> consistent through lint tests. What I don't know however is what that
> style should look like.
> 
> So, two topics:
> 
> 1. TRUE/FALSE
> Do we want such defines? If so, TRUE/FALSE, or true/false, or
> True/False, or ...?

Standardize on stdbool.h, bool, true, false. It's the logical choice.

> 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, no. Who wants 64 defines? Seriously, this sort of stuff raises
blood pressure.

BIT(16), sure. Actually, I used this trick a while back on the allwinner
port. BIT(16) meant "just a bit", whereas (1 << 16) meant an enum
(usually also paired close to 2 << 16, 3 << 16, etc).

0x10000 also fine. If it's in a list of defines, why not?

#define RON 0x8000
#define JOHN 0x10000
#define MARY 0x20000


We all know Chromium guys like to copy paste code from all over the
interwebs, and quite frankly, why make their lives harder with harsh
guidelines? These are small inconsistencies that I don't think bother
anyone too much.

Alex