From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH 0/5] Clean up header guards again
Date: Mon, 19 Jan 2026 10:46:08 +0000 [thread overview]
Message-ID: <aW4LcOkEqpPCq9sH@redhat.com> (raw)
In-Reply-To: <20260119100537.463312-1-armbru@redhat.com>
On Mon, Jan 19, 2026 at 11:05:32AM +0100, Markus Armbruster wrote:
> Our use of header guards is rather sloppy. Sloppiness there can lead
> to confusing compilation errors. This series cleans up existing
> header guards. In particular, it normalizes guard symbols to follow a
> common pattern, in the hope of making clashes less likely. It doesn't
> add new header guards. We have more than 300 headers without a
> recognizable header guard. A few of them are for multiple inclusion,
> many don't need header guards because they don't do anything but
> include, but quite a few probably should have one. Left for another
> day.
>
> Previously cleaned up in merge commit ec11dc41eec (2022), merge commit
> 01807c8b0e9 (2019), and merge commit ca3d87d4c84 (2016).
No objection to applying these fixups since you've done the work
already.
Based on the repeated cleanups, and your notes above that we still
have many problems though, can I again suggest we just adopt the
GCC/CLang extension of adding
#pragma once
at the top of every header and burn all the #ifdefs.
It is easy & cheap to verify that it is present on every single .h file,
and there are no style variations to get wrong, or closing statements to
make inconsistent.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
prev parent reply other threads:[~2026-01-19 10:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 10:05 [PATCH 0/5] Clean up header guards again Markus Armbruster
2026-01-19 10:05 ` [PATCH 1/5] scripts/clean-header-guards: Update exclusions Markus Armbruster
2026-01-19 10:33 ` Daniel P. Berrangé
2026-01-19 10:05 ` [PATCH 2/5] Clean up header guards that don't match their file name Markus Armbruster
2026-01-19 10:35 ` Daniel P. Berrangé
2026-01-19 10:05 ` [PATCH 3/5] Clean up ill-advised or unusual header guards Markus Armbruster
2026-01-19 10:35 ` Daniel P. Berrangé
2026-01-19 15:09 ` Warner Losh
2026-01-19 10:05 ` [PATCH 4/5] Normalize header guard symbol definition Markus Armbruster
2026-01-19 10:35 ` Daniel P. Berrangé
2026-01-19 10:05 ` [PATCH 5/5] Clean up decorations and whitespace around header guards Markus Armbruster
2026-01-19 10:36 ` Daniel P. Berrangé
2026-01-19 10:46 ` Daniel P. Berrangé [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aW4LcOkEqpPCq9sH@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox