From: R0b0t1 <r030t1@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] memset_s
Date: Fri, 10 Nov 2017 10:25:36 -0600 [thread overview]
Message-ID: <CAAD4mYj8foKjO7LShWcdttm7NSPEfo8pnj1TavVjxyAZSSRmmA@mail.gmail.com> (raw)
In-Reply-To: <CAKpSnpJ-FrOBttWNbOqiDxNLnQ5kTsHAbTNgZvRUSgL4hUxb=w@mail.gmail.com>
Hello,
On Fri, Nov 10, 2017 at 5:34 AM, Jorge Almeida <jjalmeida@gmail.com> wrote:
> On Fri, Nov 10, 2017 at 10:52 AM, Marc Joliet <marcec@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
next prev parent reply other threads:[~2017-11-10 16:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-10 9:54 [gentoo-user] memset_s Jorge Almeida
2017-11-10 10:52 ` Marc Joliet
2017-11-10 11:34 ` Jorge Almeida
2017-11-10 16:25 ` R0b0t1 [this message]
2017-11-10 18:20 ` Alexander Kapshuk
2017-11-10 20:09 ` Jorge Almeida
2017-11-10 23:19 ` R0b0t1
2017-11-11 0:10 ` Jorge Almeida
2017-11-13 3:03 ` Mart Raudsepp
2017-11-13 7:17 ` Jorge Almeida
2017-11-13 10:44 ` [gentoo-user] memset_s Nikos Chantziaras
2017-11-13 11:16 ` Jorge Almeida
2017-11-13 11:38 ` Mart Raudsepp
2017-11-13 14:26 ` Nikos Chantziaras
2017-11-14 17:36 ` [gentoo-user] memset_s Jorge Almeida
2017-11-15 4:42 ` R0b0t1
2017-11-15 7:22 ` Jorge Almeida
2017-11-15 15:28 ` [gentoo-user] memset_s Grant Edwards
2017-11-15 15:41 ` R0b0t1
2017-11-15 15:48 ` R0b0t1
2017-11-15 21:42 ` Grant Edwards
2017-11-16 0:19 ` R0b0t1
2017-11-15 15:50 ` Jorge Almeida
2017-11-15 17:39 ` Michael Orlitzky
2017-11-15 8:54 ` Nikos Chantziaras
2017-11-15 9:05 ` Jorge Almeida
2017-11-15 10:31 ` Nikos Chantziaras
2017-11-10 11:38 ` Nikos Chantziaras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAD4mYj8foKjO7LShWcdttm7NSPEfo8pnj1TavVjxyAZSSRmmA@mail.gmail.com \
--to=r030t1@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox