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

2016-02-10 Thread Alex G.
On 02/08/2016 11:29 AM, Julius Werner wrote: >>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: 2016-02-04 10:35 GMT+01:00 Patrick Georgi : > during the review of some commits that are in the process of being > upstreamed from Chrome OS, people noticed

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

2016-02-08 Thread ron minnich
makes sense to me. On Mon, Feb 8, 2016 at 3:10 AM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote: > 2016-02-04 10:35 GMT+01:00 Patrick Georgi : > > during the review of some commits that are in the process of being > > upstreamed from Chrome OS, people noticed

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

2016-02-08 Thread Patrick Georgi via coreboot
2016-02-04 10:35 GMT+01:00 Patrick Georgi : > 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

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

2016-02-08 Thread Nico Huber
On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: > 2016-02-04 10:35 GMT+01:00 Patrick Georgi : >> 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

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

2016-02-08 Thread Julius Werner
>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote: >> > 2016-02-04 10:35 GMT+01:00 Patrick Georgi : >> >> 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

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

2016-02-04 Thread Patrick Georgi via coreboot
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

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

2016-02-04 Thread Nico Huber
On 04.02.2016 22:25, Patrick Georgi via coreboot wrote: > 2016-02-04 22:22 GMT+01:00 Martin Roth : >> I don't think we need redefinitions of TRUE/FALSE > We have no canonical definitions for TRUE/FALSE right now. > Contributions that use them (for whatever reason) tend to bring

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

2016-02-04 Thread ron minnich
Nico, I agree with you completely: non-zero is true, zero false. It's C. But I am starting now to feel like a dinosaur, b/c "Oh, and I'm trying to hang with the cool kids and use bool :)" -- Rusty It makes me want to start an emo coreboot programmer feed like this one:

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

2016-02-04 Thread Timothy Pearson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/2016 04:22 PM, ron minnich wrote: > Nico, I agree with you completely: non-zero is true, zero false. It's C. > But I am starting now to feel like a dinosaur, b/c > "Oh, and I'm trying to hang with the cool kids and use bool :)" -- Rusty > >

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

2016-02-04 Thread Martin Roth
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, 0x1, or (1 << 16) but #define VENDOR_BIT_16 0x1 seems like overkill. I'd really generally prefer some good definitions though instead of

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

2016-02-04 Thread Vadim Bendebury
On Thu, Feb 4, 2016 at 2:00 PM, Nico Huber wrote: > On 04.02.2016 22:25, Patrick Georgi via coreboot wrote: >> 2016-02-04 22:22 GMT+01:00 Martin Roth : >>> I don't think we need redefinitions of TRUE/FALSE >> We have no canonical definitions for TRUE/FALSE right

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

2016-02-04 Thread Patrick Georgi via coreboot
2016-02-04 22:22 GMT+01:00 Martin Roth : > I don't think we need redefinitions of TRUE/FALSE We have no canonical definitions for TRUE/FALSE right now. Contributions that use them (for whatever reason) tend to bring local copies, and that's what I'd like to avoid. > How would

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

2016-02-04 Thread ron minnich
Vendors frequently ask us to use magic numbers, and have even requested at times that we remove explanatory text. We'll never get rid of magic numbers in this world :-( ron On Thu, Feb 4, 2016 at 1:25 PM Patrick Georgi wrote: > 2016-02-04 22:22 GMT+01:00 Martin Roth

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

2016-02-04 Thread Nico Huber
On 04.02.2016 10:35, Patrick Georgi via coreboot wrote: > 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. That's a good idea. > 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1 > I don't

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

2016-02-04 Thread 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

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

2016-02-04 Thread ron minnich
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 0x1 > I don't think