On Fri, Nov 10, 2017 at 6:25 PM, R0b0t1 <r03...@gmail.com> wrote:
> Hello, > > On Fri, Nov 10, 2017 at 5:34 AM, Jorge Almeida <jjalme...@gmail.com> > wrote: > > On Fri, Nov 10, 2017 at 10:52 AM, Marc Joliet <mar...@gmx.de> wrote: > >> Am Freitag, 10. November 2017, 10:54:53 CET schrieb Jorge Almeida: > >>> I'm trying to use memset_s() but the system (glibc?) doesn't know > >>> about it. I also tried to compile against musl, same result. > >>> > > > > > >> It seems as though it is simply not implemented, I found a variety of > links > >> that all support this: > >> > >> https://stackoverflow.com/a/40162721 > >> > >> https://stackoverflow.com/questions/38322363/when-will- > the-safe-string-functions-of-c11-be-part-of-glibc > >> > >> https://gcc.gnu.org/wiki/C11Status (which states that Annex K is not > >> implemented) > >> > >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm > >> > > OK, thanks. The last link even suggests that Annex K should be > > deprecated. I suppose this people don't care about security at all. > > > > I'm having trouble finding the article again, but these functions look > very similar to Microsoft's extensions to the C standard. There is a > good case to be made that they are counterproductive. > > > Of course, what would really solve the optimize-into-oblivion problem > > is a pragma that when invoked on a particular block of code (maybe > > only a function definition) would tell the compiler to do what the > > programmer says rather than viewing a function as a kind of black box. > > > > This would probably be useful. It may be wise to reimplement important > functionality. > > Cheers, > R0b0t1 > > It's also a part of NetBSD's libc used by Apple. https://opensource.apple.com/source/Libc/Libc-1044.1.2/string/NetBSD/memset_s.c
