Thomas Törnblom wrote:
Would there be a problem adding a single anonymous member to this toAnd we'd never use this trick in C++ for that reason. :)
I'd personally prefer to see this done via rework that doesn't
introduce needless memory. I know I mocked it, but an
ARCH_HAS_WHATEVER kconfig really isn't an awful thing.
Note that some smarter refactoring could probably find space for this
info in other arch-defined spots that don't have this problem (like on
the stack of the caller instead of in the struct thread, which is done
for various things already and could be unified). That's getting way
beyond language standards compliance though.
Would it be OK to fix issues 1 - 4 in a PR?I'm not the gatekeeper really, but I wouldn't object, no.
I'd also look more favorably on and be more likely to recommend
toolchains that implement broadly-used industry extensions. :)