David, apropos your comment that we can assume clang will catch any
real problems; your comment reminds me of a lesson we learned on
Harvey-OS.
What we learned on Harvey-OS, when we were compiling a working kernel
across 3 versions of gcc, and 3 versions of clang, was that at one
time or another,
Thanks for digging up all that useful information, Martin! So `#pragma
once` is not the clear winner after all. Too bad since we could eliminate
some boilerplate code with that approach.
Is there another way to solve the problem Arthur raised in this thread? The
LMKL thread had a python script and
we have, in the past, used Linux kernel style as our guideline on
coreboot style.
I'd say, based on Martin's note, that #pragma once is not such a good
idea after all. If we decide NOT to use it, however, let's put a note
about it in our style guide?
This is not the first time this question has c
After reading what I've included below, I'm going to have to vote to keep the
guards.
Martin
May 16, 2022, 10:59 by david.hendri...@gmail.com:
> On Mon, May 16, 2022 at 8:59 AM ron minnich wrote:
>
>>
>> btw, sometimes this has gone the other direction ..
>> https://github.com/lowRISC/opentitan
Hi Arthur,
I'm very much in favor of using #pragma once instead of the include
guards in the coreboot tree, since that removes the possibility of some
sorts of bugs and also removes 2 lines of boilerplate per header file.
Not sure if romcc supported #pragma once and if that was one of the
reas
I was sure I'd looked at this at one point and found this from years ago ...
"The discussion evolved to a related question, around #pragma once. A
few years back, on the Akaros project (kernel written in C, FWIW), a
Linux kernel luminary convinced us to get rid of file guards and go to
#pragma on
On Mon, May 16, 2022 at 8:59 AM ron minnich wrote:
>
> btw, sometimes this has gone the other direction ..
> https://github.com/lowRISC/opentitan/pull/5693
It looks like they did that solely to conform to Google's style guide
which, dogmatic as it may appear, makes sense since OpenTitan is a
Goog
btw, sometimes this has gone the other direction ..
https://github.com/lowRISC/opentitan/pull/5693
On Mon, May 16, 2022 at 3:04 AM Angel Pons wrote:
>
> Hi Arthur, list,
>
> On Sun, May 15, 2022 at 6:56 PM Arthur Heymans wrote:
> >
> > Hi
> >
> > To make sure headers don't create conflicts, guar
The next quarterly release, 4.17 is targeted for May 30, 2022.
Additionally, at that time, we plan to update the release packages and version
numbers any of the coreboot branches which have been modified since they were
released. Going forward, this should happen anytime there's a new release.
Hi Arthur, list,
On Sun, May 15, 2022 at 6:56 PM Arthur Heymans wrote:
>
> Hi
>
> To make sure headers don't create conflicts, guards are added to all of them.
> But the guard needs to be correct: e.g.
> https://review.coreboot.org/c/coreboot/+/64360/2
> Most compilers implement '#pragma once '
On Sun, 15 May 2022 at 19:56, Arthur Heymans wrote:
> Most compilers implement '#pragma once ' as an alternative.
I've been using #pragma once since 2019 in fwupd and I've never once
had a problem with it -- and we compile with a lot of weird compilers
and for a lot of strange targets. It reduced
11 matches
Mail list logo