Ha. How should one take such a comment?
Calling something a "disgusting hack," isn't inherently insulting, it is just a description of how well self documenting and obvious its workings are, which in this case is not at all. Whereas calling something a "work of art" particularly from Linus is high praise.
And while there is some subjectivity to if something is a "hack" or not, the original author doesn't even seem to contend that too much. They were more interested in pointing out that this method likely works across compilers (since it relies on less undefined behaviour than it might first appear).
In any case, it is a neat trick, that I wouldn't want to run across in a codebase since I'd have to spend too long figuring it out.
"this will break the minds of everybody who ever sees that expression"
Challenges the perception and pushes what is possible.
The trick can be properly documented in a page of text and wrapped in a macro... (D'oh!)
It is probably non-conforming anyway or depends on a choice made by the implementation.
https://www.uni-goettingen.de/de/uecker-martin-prof-dr-----c...
Maybe... I hesitate to call it "bad" unless there's a clearly better solution to the problem.
Even if it's horrible, in a kernel you might want macros like these if a function call would sit in a hotpath and induce overhead.
It took me a while to figure that 0l is 0 with lowercase "L"
Whatever font that site uses makes it very very hard to distinguish l and 1.
sizeof(int) == sizeof(void)
sizeof(int) == sizeof(int)
Gcc it didn't fold it during preprocessing for a fully constant expression, which is allowed. In which case always sizeof(void) is a valid answer. Which is a compile error.
That is at least what C99 draft seems to say.
I'll check C11 draft next. Edit: same.