Skip site navigation (1)Skip section navigation (2)
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>