On 11/21/2011 04:37 PM, Linus Torvalds wrote:
On Mon, Nov 21, 2011 at 3:47 PM, David Daney<firstname.lastname@example.org> wrote:
These symbols are on dead code paths, so they are eliminated by the
compiler's Dead Code Elimination (DCE) optimizations, and the BUG() code
never gets emitted to the final executable.
If you are so damn sure of that, then DON'T MAKE IT A BUG_ON! If you
are 100% syre, then you might as well leave out the BUG_ON() entirely.
Seriously. What's so hard to understand?
Really Linus, did you read the other half of the message you quoted?
The part you quote above explains the reason things are the way they
The second part, that I think you may have missed, is the part I had
hoped you would read...
Either you are 100% sure, or you are not. If you are 100% sure, then
the BUG_ON() is pointless. And if you are not, then the BUG_ON() is
Notice? The BUG_ON() is never *ever* valid. You cannot have it both
ways. So stop pushing crap, already!
So what are non-crap solutions?
- the current one: error out at compile time (early) if somebody uses
them in invalid contexts.
This seems to be a good case, especially since apparently no actual
current code wants to use them outside of the existing #ifdef's. And
there is no reason to think that some random MIPS-only future code is
a good enough reason to re-introduce these things
- if you really want to use them, but expect the compiler to always
compile them away as dead code, use a non-existing function linkage,
so that you at least get a static failure at link-time for incorrect
code, rather than some random BUG_ON() at run-time that may be
impossible to find.
See? There are real solutions. BUG_ON() is not one of them.
... because it said exactly what you say above.
I will send you a patch within the next two hours that shows what may be
an acceptable solution.