On Thu, Sep 17, 2026 at 09:44:24PM -0700, Kees Cook wrote: > On Thu, Sep 17, 2026 at 06:21:19PM -0700, Nathan Chancellor wrote: > > While we could certainly try to cook something like this up, we could > > also avoid the split across two files by just defining the flags in > > Kconfig directly and using them in the Makefile through their symbol, > > like we already do for -Wimplicit-fallthrough. For example, instead of > > > > config CC_HAS_STRICT_FLEX_ARRAYS > > def_bool $(cc-option,-fstrict-flex-arrays=3) > > > > KBUILD_CFLAGS += $(if > > $(CONFIG_CC_HAS_STRICT_FLEX_ARRAYS),-fstrict-flex-arrays=3) > > > > We would just do > > > > config CC_STRICT_FLEX_ARRAYS > > string > > default "-fstrict-flex-arrays=3" if > > $(cc-option,-fstrict-flex-arrays=3) > > > > KBUILD_CFLAGS += $(CONFIG_CC_STRICT_FLEX_ARRAYS) > > > > While we still get the duplication (and we could look at getting rid of > > it with your cc-option-str idea or whatever), it is at least contained > > to the same location, so out of sync issues should be much rarer. I do > > diff Kconfigs so this might make certain issues with checks a little bit > > more obvious if something changes on the compiler side. > > Yeah, and note that cc-option-bit already exists. It's just a weird name > is all and there isn't an ld-option-bit.
Ah, I see. I worry that the current cc-option-bit is not sufficient for all options that we may want to test because it uses '-E' to stop after preprocessing (whereas some options may need to get to code generation to be validated properly) and it does not use $(CLANG_FLAGS) to properly set the target (so we might not get consistent results). I wonder if we would be better off refactoring cc-option-bit into cc-option-str that shares most of the machinery of cc-option. Then we could just add ld-option-str. > As for naming conventions, I think "CC_OPT_" would be a good prefix. And > this works today with no change: > > config CC_OPT_STRICT_FLEX_ARRAYS > string > default "$(cc-option-bit,-fstrict-flex-arrays=3)" This does look pretty nice. > (do we need "def_string" now?) def_string would certainly make these even nicer. -- Cheers, Nathan
