From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3DD1E17C.7000404@null.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: Subject: Re: [9fans] how to avoid a memset() optimization Date: Wed, 13 Nov 2002 10:16:07 +0000 Topicbox-Message-UUID: 1c8f52ba-eacb-11e9-9e20-41e7f4b1d025 Russ Cox wrote: > My problem with volatile is that it means ``something > weird is going on here'' but doesn't tell you what. No, it mens "compiler, the access must really be performed". It is the programmer who decides whether that is a requirement, and it could be for numerous reasons, such as to assist in debugging, because the "location" is a portal to an external device register, because the object is shared among threads, etc. In this particular case it would be because the programmer really wants the memory overwrite to occur regardless of whether it is used any further. >> You're right here, but for me defining secmemset >> is much bigger evil than just adding volatile to >> the buffer. > Why? For one thing, it doesn't work (unless you force volatile qualification within secmemset), because the invocation of secmemset can be optimized away also. (It is less likely than for memset, but it is a possibility when the compiler can see the caller and callee.) Also you're in effect just replacing the standard library function with your own implementation, which will in general be slower (a trade-off you might be willing to make) and one more interface to specify (assuming a professional software environment as opposed to just hacking). In general one should have better things to do than duplicating standard library functions.