linux-kernel - Re: [RFC/PATCH] doc: volatile considered evil

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: <m3k5vj2iha.fsf@maximus.localdomain>
Date:	Tue, 08 May 2007 22:00:49 +0200
From:	Krzysztof Halasa <khc@...waw.pl>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Sokolovsky <pmiscml@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH] doc: volatile considered evil

David Rientjes <rientjes@...gle.com> writes:

> Since 'volatile' has two different semantics depending on the context in 
> which it is used, this warning should be appended to include the fact that 
> it is legitimate to use for inline assembly.

I think it hasn't two semantics, it's like arguing that char has two
semantics.

Volatile does one thing - prohibits C compiler from optimizing
accesses to the variable. Either with (volatile *) casts and with
volatile var;

Linus is right in that volatile != direct access to the hardware
and direct sync between all CPUs. Yes, most uses in high level code
are probably bugs. OTOH, there are other uses where optimizing must
be prohibited. It doesn't matter which form
is used, in fact
	volatile type name;
	name
is equivalent to:
	type name;
	*(volatile type *)&name;
At least as long as "volatile" keyword is concerned.
-- 
Krzysztof Halasa
-
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/