linux-kernel - Re: [PATCH] "volatile considered harmful", take 3

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: <464CEA70.1080908@tmr.com>
Date:	Thu, 17 May 2007 19:51:12 -0400
From:	Bill Davidsen <davidsen@....com>
To:	Satyam Sharma <satyam.sharma@...il.com>
CC:	7eggert@....de, "H. Peter Anvin" <hpa@...or.com>,
	Jonathan Corbet <corbet@....net>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, Johannes Stezenbach <js@...uxtv.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Heikki Orsila <shdl@...alwe.fi>,
	jimmy bahuleyan <knight.camelot@...il.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: [PATCH] "volatile considered harmful", take 3

Satyam Sharma wrote:

> *Unfortunately* (the trouble with C itself, is that a *committee* has made
> it into ... something ... that it should not have made it into) -- anyway,
> unfortunately C took it upon itself to solve a problem that it did not
> have (and does not even bring about) in the first place: and the
> half-hearted (or vague, call it what you will) attempt _then_ ends up
> being a problem -- by making people _feel_ as if they are doing things
> right, when that is probably not the case.
> 
> [ And we've not even touched the issue of whether the _same_ compiler's
> implementation of volatile across archs/platforms is consistent. ]
> 
Pardon, I was GE's representative to the original X3J11 committee, and 
'volatile' was added to "codify existing practice" which is one of the 
goals of a standard. The extension existed, in at least two forms, to 
allow handling of memory mapped hardware. So the committee did not take 
it upon itself, it was a part of the defined duty of the committee.

The intents was simple, clear, and limited, to tell the compiler that 
every read of a variable in source code should result in a read, at that 
point in the logic, and similar for writes. In other words, the code 
should not be moved and should generate a real memory access every time. 
People have tried to do many things with that limited concept since, 
some with "clarification" and some with assuming the compiler knows when 
to ignore volatile.

As someone noted about a committee, a committee is a poor way to get 
innovation, and a good way to have a bunch of know legible people shoot 
down bad ideas.

It was a fun experience, where I first learned the modern equivalent of 
Occam's Razor, Plauger's "Law of least astonishment," which compiler 
writers regularly violate :-(

-- 
Bill Davidsen <davidsen@....com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
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/