Hi
Those arguments not to use #pragma once make a lot of sense. Thanks Martin!
I've made some good progress on getting boards to build with clang (each
x86 board now builds). Clang at least warns about #ifndef and #define lines
not being equal so we'd have that check covered.
Kind regards
Hi Martin,
To support #pragma once, the compiler tries to identify duplicate encounters
with the same file, but the check gcc actually performs to establish the
identity of the file is weak. Here's someone who made two copies of the same
header with different names, each with a #pragma once,
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
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
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 ..
>>
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
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 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
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,
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
On Sun, May 15, 2022 at 11:56 AM 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
A few more that I noticed by grepping around:
13 matches
Mail list logo
