On 08.12.2016 16:23, Eric Blake wrote: > On 12/07/2016 08:28 PM, Gonglei (Arei) wrote: > >>> As far as I'm aware, other projects usually have a special memset >>> variation for doing this. That is because compilers may choose to >>> "optimize" memset(p, ...) + free(p) to just the free(p). Having a >> >> Actually, I googled this, but I didn't find a definite answer. And >> >> The Linux kernel uses kzfree instead of memset + kfree (mm/slab_common.c).
Well, I personally don't mind whether we use a custom zfree() or a custom memset_s() + free(). I only mind that this patch actually always does what it is intended to do. > If we're worried about cleaning things without allowing the compiler a > chance to optimize, then writing our own qemu_zfree() wrapper may indeed > make sense. But that won't cover the case in Daniel's earlier patch > (referenced elsewhere in this thread), as that was zeroizing stack > memory (before it went out of scope) rather than heap memory (before > free). So you'd still need some sort of 'write this memory no matter > what' primitive that would be directly usable on stack memory and > indirectly used as part of the qemu_zfree() wrapper. > > But I wouldn't worry about it for now, unless someone proves we actually > have a compiler optimizing away the cleanups. It's true that we don't have to worry about it *now*, but the approach of waiting until the compiler breaks it does not seem right to me. If at some point some compiler recognizes g_free() as being the same function as free() and thus optimizes memset() + g_free(), we simply won't notice because nobody will keep track of the generated assembly output all the time. There is a reason C11 introduced memset_s(), and it is this. Max
signature.asc
Description: OpenPGP digital signature
