On Wed, 16 Apr 2014 20:25:39 -0400 > That's exactly the situation here. The lifetime of the object being > cleared by memset ends sufficiently close to the memset that the > compiler is able to achieve the same observable effects that would be > seen in the abstract machine without actually performing any memory > fill.
There are several possibilities out there in the wild that currently work around the (unimplemented, everywhere) microsoft _s "extension". 1) memset(ptr, 0, length-of-ptr-to-data); #define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory") barrier_data(ptr); 2) through volatile function pointer for C99 (that's what we have ATM) typedef void *(*memset_fn_t)(void *,int,size_t); static volatile memset_fn_t memset_fun = &memset; void my_c99_memset(void *ptr, size_t len) { memset_fun(ptr, 0, len); } Several, e.g. https://klevchen.ece.illinois.edu/pubs/yjoll-usesec17.pdf 3) ... Hence 1) is what's currently used in the kernel (include/linux/compiler.h, barrier_data). I'd do that, too, for now, IMO. and there's -fno-inline-memset for compiling nuke, but i haven't looked in detail if that confuses DSE enough to give up on the memset in our nuke. HTH, _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox