linux-kernel - Re: Is gcc thread-unsafe?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 26 Oct 2007 08:09:05 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bart Van Assche <bart.vanassche@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Is gcc thread-unsafe?

On Fri, 26 Oct 2007, Bart Van Assche wrote:
> On 10/25/07, Linus Torvalds <> wrote:
> > 
> > The gcc developers seem to have had a total disregard for what people
> > want or need, and every time some code generation issue comes up, there's
> > a lot of people on the list that do language-lawyering, rather than admit
> > that there might be a problem.
> 
> Please make a proposal for how gcc should be modified instead of just
> shooting on the gcc people -- the root cause here is the way the C/C++
> memory model is defined. (Note: I'm not in any way involved in gcc
> development.)

Note that I'm very ambivalent about gcc. I think it's a *great* compiler. 
I have my doubts about some of the things it does, but hey, it is an old 
project, it has accumulated cruft over time, and cleaning things up is 
often almost impossible.

And bugs happen. I'm not complaining about that at all either, even if 
sometimes a compiler bug is damn frustrating.

And the fact is, most of the gcc developers are great.

So my basic worry about gcc is in fact none of the individual technical 
problems themselves - those can be fixed. No, the problem I've seen in gcc 
is that _some_ of the developers seem to be total d*ckheads when it comes 
to "language definition", and seem to think that it's more important to 
read the language spec like a lawyer than it is to solve actual user 
problems.

And that has come up before. It has nothing to do with this particular 
"gcc doesn't create thread-safe code" issue. We had the exact same issue 
with gcc creating totally unusable code due to having a fundamentally 
braindead memory aliasing model. The language-lawyering people basically 
could push their *idiotic* model onto gcc, just by quoting the standard, 
and not caring about actual users at all.

And that's a problem. In the kernel, we've historically always cared a lot 
about POSIX and SuS, but while conforming to standards have been primary 
goals since pretty much day one (ie I asked around about POSIX before the 
very first release, and it's how I met some suckers^Wupstanding citizens 
to try those early kernels), it has *always* taken a back seat to things 
like compatibility with existing apps.

The gcc lists seem to often get to the point where people quote the 
standard, and that's that. In that environment, the paper standard (that 
hass *nothing* to do with reality) trumps any other argument. "What we do 
is _allowed_ by the standard" seems to be a good argument, even if it 
breaks real code and there is no sane way to avoid doing it.

And I really don't think it's everybody. At all. But I think it's the case 
that sometimes it's easier to quote the standard than write good code, and 
so gcc lists have more people quoting the papers than trying to fix some 
problem.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/