linux-kernel - Re: [PATCH 1/1] compiler.h: Add missing include statement for build

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgn=e3gD=tty+p1o8HBy7qxBCgCHiDEd5+FMtn9jdwd2g@mail.gmail.com>
Date: Thu, 14 Nov 2024 09:42:15 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Philipp Reisner <philipp.reisner@...bit.com>, Kees Cook <keescook@...omium.org>
Cc: Luc Van Oostenryck <luc.vanoostenryck@...il.com>, linux-sparse@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] compiler.h: Add missing include statement for build_bug.h

On Thu, 14 Nov 2024 at 02:23, Philipp Reisner
<philipp.reisner@...bit.com> wrote:
>
> compiler.h defines __must_be_array() and __must_be_cstr() and both
> expand to BUILD_BUG_ON_ZERO(). build_bug.h defines BUILD_BUG_ON_ZERO().
> So far compiler.h lacks to include build_bug.h.

The bug is real, but..

> Fix compiler.h by including build_bug.h. With that compiler.h and
> build_bug.h depend on each other.

I hate how compiler.h would include build_bug.h, which - on the very
first line - then in turn includes compiler.h.

Does it *work*? Yes. The standard include guards stop the thing from
recursing, and both headers only do create pre-processor defines, so
the dependencies aren't ordered, but it's really really ugly to have
these kinds of circular includes.

I think a better fix would be to not use BUILD_BUG_ON_ZERO() at all,
but just use _Static_assert() directly here, to make
<linux/compiler.h> be more self-sufficient.

The gcc docs say that __builtin_types_compatible_p() and
__builtin_has_attribute() both return an integer constant expression,
so that should be fine (the advantage of BUILD_BUG_ON_ZERO() is that
it works in some contexts that aren't necessarily technically integer
constant expressions - as long as they just evaluate to a constant).

We historically used to avoid _Static_assert(), but that was for
historical reasons (ie it's one of those things that didn't exist back
in the day..)

Hmm?

              Linus