Date: Thu, 30 Mar 2017 00:51:04 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r316213 - in head: include lib/libc/include lib/libc/stdlib lib/libc/string lib/libc/tests/stdlib lib/libc/tests/string sys/sys Message-ID: <82479073-92cf-380c-5f4c-c33aa31bb1b3@FreeBSD.org> In-Reply-To: <20170330050012.GW43712@kib.kiev.ua> References: <201703300457.v2U4vQJw072106@repo.freebsd.org> <20170330050012.GW43712@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks! On 30/3/2017 00:00, Konstantin Belousov wrote: > On Thu, Mar 30, 2017 at 04:57:26AM +0000, Konstantin Belousov wrote: >> Author: kib >> Date: Thu Mar 30 04:57:26 2017 >> New Revision: 316213 >> URL: https://svnweb.freebsd.org/changeset/base/316213 >> >> Log: >> Implement the memset_s(3) function as specified by the C11 ISO/IEC >> 9899:2011 Appendix K 3.7.4.1. > Due to (somewhat) controversial nature of the specification, it > was agreed that only memset_s() is added, as the function which > has real users, even if outside the tree. There is no plans to > add other functions, unless somebody needs them. Apple's libc also implemented memset_s() based on some draft implementation from NetBSD. This one looks better. > If people are curious what are the issues with the Appendix K, > please see documents > N1173 Rationale for TR 24731 Extensions to the C Library Part I: > Bounds-checking interfaces > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1173.pdf > N1967 Field Experience With Annex K > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm > from the JTC1/SC22/WG14 - C working group. > > Very interesting, thanks! We looked at the spec for a GSoC but ultimately we ended up spending a lot more time on FORTIFY_SOURCE and left it aside. Ultimately we also left FORTIFY_SOURCE aside but someone has to try such experiments :). The annex K is basically a Microsoft thing (I think I read about glibc adopting it experimentally though). I think it should be useful to have it as an external library for portability, not part of libc or even base. I also find interesting that you included an error handler. Perhaps this may be useful for other types of runtime bounds checking like the stack canaries, safe stack or even the sanitizers. I haven't really looked but we still depend on a GCC library (libssp) for the stack protector so we have a can of worms there. Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82479073-92cf-380c-5f4c-c33aa31bb1b3>