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...
I like the idea of using C11.
best, lynxis
On 29.11.2016 00:23, Alexander Couzens wrote:
I like the idea of using C11.
I would be looking forward to that.
Nico
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
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.)
Paul can you please - without looking it up - name two new features of C99 compared to C89?
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
On Tue, 29 Nov 2016 09:09:48 +0100 Gerd Hoffmann kraxel@redhat.com 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.
On Tue, Nov 29, 2016 at 1:40 PM, Stefan Tauner < stefan.tauner@alumni.tuwien.ac.at> wrote:
On Tue, 29 Nov 2016 09:09:48 +0100 Gerd Hoffmann kraxel@redhat.com 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.
On Di, 2016-11-29 at 22:40 +0100, Stefan Tauner wrote:
On Tue, 29 Nov 2016 09:09:48 +0100 Gerd Hoffmann kraxel@redhat.com 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
-
Alexander Couzens -
David Hendricks -
Gerd Hoffmann -
Julius Werner -
Nico Huber -
Paul Menzel -
Stefan Tauner