From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roman V. Shaposhnick" To: 9fans@cse.psu.edu Subject: Re: [9fans] how to avoid a memset() optimization Message-ID: <20021113042632.A6338@unicorn.math.spbu.ru> References: <01974d0bd36314a7c8172b6eca15effe@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <01974d0bd36314a7c8172b6eca15effe@plan9.bell-labs.com> Date: Wed, 13 Nov 2002 04:26:32 +0300 Topicbox-Message-UUID: 1c5a3454-eacb-11e9-9e20-41e7f4b1d025 On Tue, Nov 12, 2002 at 07:31:13PM -0500, Russ Cox wrote: > > Plan9 has its own C compiler ) but seeing how gcc is making its > > way, it seems that declaring every buffer volatile ( as John the > > moderator has suggested ) wouldn't hurt either. > > I disagree. It hurts readability and clarity, all > to avoid a bug in gcc. Putting aside issues with optimizing compilers, I don't see a "volatile" qualifier as something that "hurts readability and clarity", I even would say, that it is exactly the case where its use is justified. Wouldn't you agree ? > If I asked it to zero the memory, then, damn it!, zero the memory. > The right fix is to avoid gcc. gcc is not the only one to blame, most of the compilers which pride themselves on doing witty optimizations are guilty as well. The point here is that "volatile" seems to be the only portable way of telling optimizer: "get away from this data". > The point is that this only happens because gcc > is inlining the memset You're right here, but for me defining secmemset is much bigger evil than just adding volatile to the buffer. The problem with volatile, of course, is that it is just a hint not a directive ( well, at least that's how I interpret C99 Standard ). Thanks, Roman.