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

[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 local
> copies, and that's what I'd like to avoid.

I don't like true/false definitions neither. If we have contributions
which bring them, well, we should factor it out during review.

Arguments against true/false definitions? It's C! As we know, in C,
everything but 0 is naturally true. While redefining true/false seems
to enhance readability, it breaks with this principle. That might not
be a problem if you write new code---you usually know how you want to
interpret true then. However if you just read code you might find a
condition like
  if (something == true)
So, I expect that this comparison is done in terms of the type of
`something` (and is only "true" if `something` evaluates to 1). Is it
like that? Well, I'm pretty sure it is. But having to think about it
is already too much IMO.

Nico

RFC: coding style: "standard" defines

[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 now.
> > Contributions that use them (for whatever reason) tend to bring local
> > copies, and that's what I'd like to avoid.
>
> I don't like true/false definitions neither. If we have contributions
> which bring them, well, we should factor it out during review.
>
> Arguments against true/false definitions? It's C! As we know, in C,
> everything but 0 is naturally true. While redefining true/false seems
> to enhance readability, it breaks with this principle. That might not
> be a problem if you write new code---you usually know how you want to
> interpret true then. However if you just read code you might find a
> condition like
>   if (something == true)

This of course brings another style point/suggestion: Boolean checks
should never involve comparing, it should be

if (something){}

or

if (!something){}

--vb
> So, I expect that this comparison is done in terms of the type of
> `something` (and is only "true" if `something` evaluates to 1). Is it
> like that? Well, I'm pretty sure it is. But having to think about it
> is already too much IMO.
>
> Nico

RFC: coding style: "standard" defines

[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:
https://twitter.com/kylor3n?lang=en
for those of us who have been using "C as it is spoken" for more than 5
years :-)

Seriously, though, I agree with you but ... the world may not :-)

ron

On Thu, Feb 4, 2016 at 2:01 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 now.
> > Contributions that use them (for whatever reason) tend to bring local
> > copies, and that's what I'd like to avoid.
>
> I don't like true/false definitions neither. If we have contributions
> which bring them, well, we should factor it out during review.
>
> Arguments against true/false definitions? It's C! As we know, in C,
> everything but 0 is naturally true. While redefining true/false seems
> to enhance readability, it breaks with this principle. That might not
> be a problem if you write new code---you usually know how you want to
> interpret true then. However if you just read code you might find a
> condition like
>   if (something == true)
> So, I expect that this comparison is done in terms of the type of
> `something` (and is only "true" if `something` evaluates to 1). Is it
> like that? Well, I'm pretty sure it is. But having to think about it
> is already too much IMO.
>
> Nico