On Mon, Apr 9, 2018 at 11:00 AM, Kees Cook <keesc...@chromium.org> wrote: > > Can we update the comment near the top to explain why we need > __UNIQUE_ID() since we've now rediscovered why it was originally > there?
Too late, since it's already committed in my tree and going through the build test paces. But I really hope somebody revisits __UNIQUE_ID, and maybe they can then add a comment to the users too. It looks like gcc needs at least version 4.3 to have a working __COUNTER__ implementation. What a coincidence - we don't really support anything older now anyway. And similarly for clang - the only versions that didn't have it are not able to build the kernel anyway. So we should remove any version conditionals, and we should remove the known-broken generic fallback that uses __LINE__ instead of __COUNTER__. And once you do that, the "prefix" is actually pointlessm and we could drop it to make __UNIQUE_ID() easier to use. The *REAL* problem, however, is that __UNIQUE_ID is such a pain to use in general. You basically have two choices: - use it as a single-declaration throwaway variable name that is never actually used - use it only in a wrapper macro that then passes it off as an argument to another macro that uses it several times That "throwaway" use sounds pointless, but it's actually the *common* use we have for this thing outside of this min/max case. It's used to shut up the compiler about other unused variables, where people do things like static __unused__ __UNIQUE_ID(xyz) = .. mark other variable as used here ..; and I think the reason it's common is that it's the only *easy* use of that unique-name-generator macro. Having to pass it off to a second macro to use as a variable name makes it cumbersome to use for most normal macro cases. It would be nice to have the equivalent of __COUNTER__ that just expanded not to a continually increasing number, but expanded to a number that expands for each macro expansion. Then you could do things like int UNIQUE(a) = (a); to generate a variable name that was unique within a particular macro expansion, and then actually _use_ UNIQUE(a) in the same macro expansion to refer to it without having to pass it off as a name to another macro that does the declaration and use. You can't use __UNIQUE_ID() for that, because every new __UNIQUE_ID(a) will give _another_ unique ID. (And you *could* use the __LINE__ based one for that, but then you'd get the whole "nasty shadowing" problem if we have nested macros again). Ugh. We have no wonderful model for unique names. Which is why we obviously just use the "add underscores until it's unique" and the get it wrong with nesting. Linus