This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Optimising away memset() calls?
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Sandy Harris <sandyinchina at gmail dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Wed, 8 Oct 2014 07:53:20 +0200 (CEST)
- Subject: Re: Optimising away memset() calls?
- Authentication-results: sourceware.org; auth=none
- References: <CACXcFm=c0kf-2M2V_D+L2PdEoD4qcqKNVmPGQkv8FRKEqw3Zmw at mail dot gmail dot com>
- Reply-to: gcc-help at gcc dot gnu dot org
On Tue, 7 Oct 2014, Sandy Harris wrote:
There is discussion in Linux mailing lists threads about code along
these lines:
some_function()
{
char temp[N] ;
...
do something that puts sensitive data in temp[]
....
memset( temp, 0, N ) ;
}
The claim is that gcc may optimise away the memset() call since that
memory will not be referenced again.
True, the difference cannot be observed in a standard program, so it makes
sense that you have to say something special to convince the compiler not
to optimize it.
There are various solutions to this. Linux now has memzero_explicit(),
I expected the kernel to be compiled with -fno-builtin-memset (or some
other option that implies this one), which would disable this
optimization.
" A real fix would make memset() do the right thing reliably; if the
" programmer puts in memset( x, 0, nbytes) then the memory should
" be cleared, no ifs or buts.
If the programmer writes 1+1, the compiler should emit an add instruction,
no ifs or buts?
--
Marc Glisse