This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C11 Annex K support


On Wed, Jan 16, 2019 at 11:59 AM Manfred <mx2927@gmail.com> wrote:
>
> 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?

As I understand things the two design goals for the safer interfaces
from Microsoft were:

(1) destination buffer size always specified so the buffer can't be
overwritten (under most circumstances)

(2) unified return codes so all the functions return error codes with
the same meaning (instead of remembering different meanings for
strcpy, snprintf, etc).

It is hard to take opposition seriously when their complaints are ones
like "you have to check a return value". Imagine that - consistent
patterns and semantics across all calls to functions that are hard to
use safely...

I've been part of four data breaches now. I'm happy to trade
"duplicating the computation of strlen" for the safety of my data.

The biggest problem with Annex K seems to be it was proposed by Microsoft.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]