Messages in this thread | | | Date | Thu, 21 Nov 2013 16:17:12 -0800 | Subject | Re: current_thread_info() not respecting program order with gcc 4.8.x | From | Linus Torvalds <> |
| |
On Thu, Nov 21, 2013 at 3:18 PM, Alexander Holler <holler@ahsoftware.de> wrote: > > Sorry, that I still disagree.
Why? You're wrong.
I mean, anybody who disagrees with me is pretty much wrong just on pure principles, but I actually mean a deeper kind of wrong than that. I mean a very objective "you're clearly wrong".
> I try to describe it more clearly why I still think that the problem might > be because of that const declaration.
.. and then you use a totally bogus example to try to "prove" your point.
The example you use has nothing to do with what the function in case actually does.
The function we actually talk about RETURNS THE SAME VALUE EVERY TIME IT IS CALLED, regardless of arguments (which it doesn't happen to have). Ergo, it is "const".
Your example is pure and utter shit, since you still get confused about what is actually const and what isn't.
The fact is, "current_thread_info()" returns a constant value (within that execution context). Always has, always will. It fundamentally HAS to, since that is - by definition - what that "thread info" is all about.
The dereference (your "->somewhere_local") happens *outside* that const function scope. And no, that dereference is not const. But that's not what we tell gcc, and never has been.
So don't try to confuse things by trying to make "current_thread_info()" something it isn't.
Basically, your whole argument boils down to "if the function did something else than what it does, then it wouldn't be const, so we shouldn't mark it const". But that argument is BULLSHIT, because the fact is, the function *doesn't* do what you try to claim it does.
Linus
| |