lkml.org 
[lkml]   [2013]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: current_thread_info() not respecting program order with gcc 4.8.x
From
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


\
 
 \ /
  Last update: 2013-11-22 01:41    [W:1.071 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site