From owner-svn-src-head@freebsd.org Thu Mar 30 06:34:26 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2C3BD25C53; Thu, 30 Mar 2017 06:34:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8AF5D2DF; Thu, 30 Mar 2017 06:34:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v2U6YMnm036639 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Mar 2017 09:34:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v2U6YMnm036639 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v2U6YMPZ036638; Thu, 30 Mar 2017 09:34:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Mar 2017 09:34:22 +0300 From: Konstantin Belousov To: Pedro Giffuni Cc: 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: <20170330063422.GY43712@kib.kiev.ua> References: <201703300457.v2U4vQJw072106@repo.freebsd.org> <20170330050012.GW43712@kib.kiev.ua> <82479073-92cf-380c-5f4c-c33aa31bb1b3@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82479073-92cf-380c-5f4c-c33aa31bb1b3@FreeBSD.org> User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 06:34:27 -0000 On Thu, Mar 30, 2017 at 12:51:04AM -0500, Pedro Giffuni wrote: > 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. >From the 'Field Experience' document I cited above, it seems that glibc agressively rejected the proposal to implement it, but I did not investigated actual mailing lists. There are self-contained libraries implementation, again judging by the referenced document. If you and others strongly prefer this thing to be thrown out into separate library, I will do that. OTOH, it is C standard interfaces, even if optional, and its presence does not affect the runtime, comparing with other standards-mandated things, like C11 threading. > > 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. My argument pro for providing the settable constraint handler was that even if implementing a single function from several dozens described by spec, we should provide all dependencies mandated by spec. People do not like the abitily to set the handler, see the referenced doc, but the patch implements relatively robust mitigation against usual objections.