Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)

[Paul Menzel]

Dear Ron,

Am Sonntag, den 27.11.2016, 22:44 +0000 schrieb ron minnich:
> Seems reasonable, but on Harvey recently we went with c11. Any reason not
> to do that instead?

I am sorry, my statement about Linux was incorrect. Linux is explicitly
built with C89 [1][2][3].

```
HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
```

So I’d say, coreboot also stays with C89 to be compatible with Linux.

Thanks,

Paul

[1] https://www.phoronix.com/scan.php?page=news_item&px=MTg0MTQ
[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51...
[3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Makefile...

[RFC] Explicitly use C11 (was: Setting C99 by default)

[Alexander Couzens]

I like the idea of using C11.

best,
lynxis

[RFC] Explicitly use C11

[Nico Huber]

On 29.11.2016 00:23, Alexander Couzens wrote:
> I like the idea of using C11.

I would be looking forward to that.

Nico

[RFC] Explicitly use C11

[Paul Menzel]

Dear coreboot folks,

Am Dienstag, den 29.11.2016, 00:38 +0100 schrieb Nico Huber:
> On 29.11.2016 00:23, Alexander Couzens wrote:
> > I like the idea of using C11.
>
> I would be looking forward to that.

As GCC 5.3 from the coreboot toolchain uses GNU11 by default, there is
now a change set up for review, explicitly setting that [1].

A lot of the GNU extensions are used in our codebase, so if somebody
feels strongly about moving away from GNU11 to C11, the code needs to
be cleaned up. But that should be done in a different patch set.

Thanks,

Paul

[1] https://review.coreboot.org/17636/

[RFC] Explicitly use C11

[Julius Werner]

> A lot of the GNU extensions are used in our codebase, so if somebody
> feels strongly about moving away from GNU11 to C11, the code needs to
> be cleaned up. But that should be done in a different patch set.

I'd like to explicitly object to that. There are many GNU extensions
which are simply necessary to write sane, readable and performant code
(e.g. to implement non-double-evaluating MIN()/MAX() macros, to
cleanly control linking into particular sections, to get performant
code generated for IO accessor functions, etc.). The C standard by
itself is simply insufficient to support all systems programming use
cases, and if we forbade GNU extensions we'd have to rewrite
significant parts of coreboot in pure assembly and add weird, hardly
readable workarounds for many code patterns. I don't see how this
would be worth it just to try to get compatibility with compilers
nobody wants to use anyway, or for some theoretical goal of "standards
compliance" with no practical benefit. (Note that many GNU extensions
are implicitly available even without -std=gnuXX, some of them even if
you also enable -Werror=pedantic. But that doesn't not make them GNU
extensions, and there'd be no reason to treat them differently from
ones that require the -std flag. Ditching GNU extensions would mean
that every __attribute__, every __builtin and every extended asm
becomes illegal.)

[RFC] Explicitly use C89 (was: Setting C99 by default)

[Stefan Tauner]

Paul can you please - without looking it up - name two new features of
C99 compared to C89?

[RFC] Explicitly use C89 (was: Setting C99 by default)

[Gerd Hoffmann]

On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote:
> Paul can you please - without looking it up - name two new features of
> C99 compared to C89?

Named initializers.
That alone is reason enough to prefer c99 over c89 IMHO.

cheers,
  Gerd

[RFC] Explicitly use C89 (was: Setting C99 by default)

[Stefan Tauner]

On Tue, 29 Nov 2016 09:09:48 +0100
Gerd Hoffmann  wrote:
> On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote:
> > Paul can you please - without looking it up - name two new features of
> > C99 compared to C89?
>
> Named initializers.
> That alone is reason enough to prefer c99 over c89 IMHO.

You are not Paul. I was asking him specifically because I don't think
that he could name them but still tries to argue about such things
although he is not proficient enough to evaluate the implications of
such decisions (and I can't stand that at all). Even with good
intentions this is a dangerous approach on improving code quality and
needs to be countered.

[RFC] Explicitly use C89 (was: Setting C99 by default)

[David Hendricks]

On Tue, Nov 29, 2016 at 1:40 PM, Stefan Tauner <
[e-mail]> wrote:
> On Tue, 29 Nov 2016 09:09:48 +0100
> Gerd Hoffmann  wrote:
> > On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote:
> > > Paul can you please - without looking it up - name two new features of
> > > C99 compared to C89?
> >
> > Named initializers.
> > That alone is reason enough to prefer c99 over c89 IMHO.
>
> You are not Paul. I was asking him specifically because I don't think
> that he could name them but still tries to argue about such things
> although he is not proficient enough to evaluate the implications of
> such decisions (and I can't stand that at all). Even with good
> intentions this is a dangerous approach on improving code quality and
> needs to be countered.

I prefer Julius's approach of giving a detailed explanation that people
reading the list can actually learn from.

[RFC] Explicitly use C89 (was: Setting C99 by default)

[Gerd Hoffmann]

On Di, 2016-11-29 at 22:40 +0100, Stefan Tauner wrote:
> On Tue, 29 Nov 2016 09:09:48 +0100
> Gerd Hoffmann  wrote:
> > On Di, 2016-11-29 at 00:41 +0100, Stefan Tauner wrote:
> > > Paul can you please - without looking it up - name two new features of
> > > C99 compared to C89?
> >
> > Named initializers.
> > That alone is reason enough to prefer c99 over c89 IMHO.
>
> You are not Paul. I was asking him specifically because I don't think
> that he could name them but still tries to argue about such things
> although he is not proficient enough to evaluate the implications of
> such decisions (and I can't stand that at all). Even with good
> intentions this is a dangerous approach on improving code quality and
> needs to be countered.

I think switching to a more modern C standard is a good approach on
improving code quality.

But, yes, taking the "just flip the switch and see what happens"
approach is dangerous as it can introduce subtle bugs due to language
changes (aliasing rules for example, don't remember whenever that was in
c99 or in c11 though).

cheers,
  Gerd