On 29-11-16 11:28, Arne Schwabe wrote: > > > Am 29.11.16 um 11:18 schrieb Gert Doering: >> Hi, >> >> On Tue, Nov 29, 2016 at 11:07:12AM +0100, Arne Schwabe wrote: >>> I think we should prefer memset_s if available since it is a C11 standard. >> Since we're currently compiling against C99, we can't rely on it being >> there (in my OS Zoo, only MacOS seems to have it, at least "have a manpage >> for it" - not even FreeBSD 11 or "gentoo current") - but then, configure >> could check that for us... > I wouldn't add a configure test for that. According to > http://en.cppreference.com/w/c/string/byte/memset: > > As all bounds-checked functions, |memset_s| is only guaranteed to be > available if __STDC_LIB_EXT1__ is defined by the implementation and if > the user defines __STDC_WANT_LIB_EXT1__ to the integer constant 1 before > including |string.h|. > > so preprocessor magic can check that.
This is indeed how it should be done (and almost how the new version of Yang et al does it). However, memset_s() is part of the *optional* annex K of C11, and there seems to be no agreement on whether it is a good idea to implemented at all[0]. Given that Windows has SecureZeroMemory() and the memory barrier approach works fine on the unixes, I don't see much gain in adding support for memset_s(). Even so, I won't object to a patch adding it, and will send a v3 if there are more people who want it. -Steffan [0] http://comments.gmane.org/gmane.comp.lib.glibc.alpha/44430 ------------------------------------------------------------------------------ _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
