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: <20021114094239.B12968@unicorn.math.spbu.ru> References: <20021114044645.B11748@unicorn.math.spbu.ru> <20021114015257.GB84613@mero.morphisms.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <20021114015257.GB84613@mero.morphisms.net> Date: Thu, 14 Nov 2002 09:42:39 +0300 Topicbox-Message-UUID: 1e46fd4c-eacb-11e9-9e20-41e7f4b1d025 On Wed, Nov 13, 2002 at 08:52:57PM -0500, William Josephson wrote: > On Thu, Nov 14, 2002 at 04:46:45AM +0300, Roman V. Shaposhnick wrote: > > Because dropping volatile creates more problems in subsequent code. > > Inexperienced maintainer might add some new code and end it with > > a call to memset() [ he is inexperienced and doesn't know about > > secmemset yet ] and he will trip over without buffer being volatile. > > > > For me this is worse. > > If it is old code, then he'll see the secmemset call and > go read up on it. If it is new code and doesn't know about > secmemset, what is the chance he will know to use volatile? He doesn't need to know about volatile -- that's the whole point. Once "experienced" programmer has set the buffer that way, the less experienced just gets less chance to screw himself up ( although, the right to screw yourself is probably one of the basic human rights, so it's not eliminated here either ). With the secmemset approach the chance is greater. Thanks, Roman.