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]

Message-ID: <alpine.LFD.0.999.0710261453160.30120@woody.linux-foundation.org>
Date:	Fri, 26 Oct 2007 15:24:44 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Giacomo Catenazzi <cate@...eee.net>
cc:	Bart Van Assche <bart.vanassche@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Is gcc thread-unsafe?

On Fri, 26 Oct 2007, Giacomo Catenazzi wrote:
> 
> So we have the great opportunity to change the standard, then
> gcc will change ;-)

I see the smiley, but sadly, new standards take ten years or more to 
mature. Which means that even if the upcoming one is "perfect", things 
will be wrong with it, if only because people will have new usage 
scenarios where the standard simply isn't relevant or that it otherwise 
just doesn't address, and that then gets us back to the same issues 
somewhere else.

So it would be much better if developers just didn't think the standard 
trumped "real and existing code and problems", and shot down the language 
lawyers (and don't get me wrong - it's not just in gcc, btw. We _have_ had 
some of the same behavior in the kernel, although I will argue that our 
"backwards compatibility trumps pretty much everything else" rules at 
least solves _some_ of the problems).

Standards are just papers. Yes, they're important, but they are definitely 
not more important than anything else, and they are a lot _less_ important 
than some people seem to think. Gcc has done more for programming by being 
a de-facto standard and widely available, than the _paper_ standards often 
ever do!

It's also sad that a lot of these things seem to be done in the name of 
optimizing code, and then in many cases it drives people *away* from using 
that optimizer for anything but benchmarking.

In the kernel, we historically used to try for extreme optimizations, 
these days we spend more time tuning the optimizations _down_ because they 
aren't optimizations at all (ie using -Os instead of -O2), or they were 
buggy enough that we have to explicitly disable them (aliasing, 
"unit-at-a-time" etc).

			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/