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.
I agree with you - I think I would take it as a compliment as well. Also, I take back my original post on what the best comment is in this post. This is better:
"this will break the minds of everybody who ever sees that expression"
I think in this life at least all that's left for Linus to enjoy are marvelously disgusting hacks. So with that understanding this is probably the ultimate compliment.
I think it's the highest compliment I've ever seen Linus express to somebody. And he's not wrong, the hack is adorable. It would never have occurred to me that doing this was even possible in C.
I didn't believe it would work but it does. It boils down to
sizeof(int) == sizeof(void)
vs
sizeof(int) == sizeof(int)
As a non-standard extension, in gcc (and thus clang and icc for compatibility, it seems) void has a size of 1. In a conforming compiler, it's an error.
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.
Hilariously that site makes no choices at all about what font to use; it merely puts the message text into a pre tag, making it monospaced. You should choose a better font to display monospaced text in.
I spent a long time wondering why it was multiplying by octal 1 as well. I'm not sure whether code like this should be critiqued for readability, but "0L" (uppercase) would have worked better.
24 comments
[ 2.9 ms ] story [ 62.5 ms ] threadHa. 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...
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.
Maybe... I hesitate to call it "bad" unless there's a clearly better solution to the problem.
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.
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.