This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: C11 Annex K support
On 1/16/2019 5:33 PM, Jeffrey Walton wrote:
On Wed, Jan 16, 2019 at 11:06 AM Florian Weimer <fweimer@redhat.com> wrote:
* Manfred:
To my surprise, it looks like glibc does not support C11 annex K
routines, i.e. strcpy_s and friends.
Am I missing something?
We consider Annex K very problematic:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm>
Lol... Strawman arguments...
I don't think I agree.
The report in n1969 makes several good points.
The objection could be that the APIs in Annex K might be seen as "better
than nothing", and just used when useful, while keeping using the
traditional ones where deemed preferable.
However:
1) This would lead to some inconsistency in coding style, even for new
code, where in some cases strcpy /should/ be used, and in some other
strcpy_s should - IOW, strcpy_s is not a good /replacement/ for strcpy,
it is an addendum at best.
2) It looks that, despite its long gestation, Annex K has not been
thought well enough, or anyway there is room for improvement. I may
understand that glibc would be trying to push for a withdrawal of Annex
K, possibly to aim for a replacement with a better API set?
libupnp multiple vulnerabilities
(https://www.kb.cert.org/vuls/id/922681/) is a good case study in how
just broke the existing stuff can be. Each of the vulnerabilities
would have been mitigated with the new interfaces because the buffer
overflow would have been stopped due to the destination buffer size.
There's a lot to be said about what happens in real life...
Jeff