Re: Implement C11 annex K?

[dalias <dalias at libc dot org>]

On Wed, Aug 13, 2014 at 03:23:29PM -0400, David A. Wheeler wrote:
> On Tue, 12 Aug 2014 19:48:17 -0400, dalias <dalias@libc.org> wrote:
> > I'd much rather see strlcpy/strlcat added.
> 
> I'd be happy to have someone work to add strlcpy/strlcat, and
> I'd be happy to focus on doing that *first*.
> After all, strlcpy/strlcat are short, well-understood, and easy-to-use.
> I see no need to put strlcpy/strlcat in a separate lib_s file, since they're short.
> Annex K has other capabilities I'd like to see, and is a formal standard, but
> staging work is fine.  I suspect that strlcpy/strlcat could help in implementing strcpy_s
> (I'd have to check to make sure).
> 
> So... would a high-quality strlcpy/strlcat patch be (FINALLY!) accepted?

I hope so, but I have no control over that other than speaking up in
favor of it.

> > > Portable application code can just set the handler, once.
> > 
> > Not necessarily. There could already be library code and multiple
> > threads running before entering main due to global ctors.
> 
> Sure, but if the default is "no constraint handler set", then a constraint
> handler won't be triggered by surprise.

Yes, but portable code can't assume that.

> > ... Library Y expects that the application using it
> > setup the constraint handler, but the application is not the "user" of
> > library Y; library X is the user.
> 
> Hold it right there!  A library that *requires* that a constraint handler be set is
> already in a state of sin, because it's perfectly legal to set up the constraint
> handler to return.

You missed the point: that's the exact constraint handler it would
_want_. But since the default is implementation-defined, it can't rely
on that being there by default. Thus, it requires an explicit
do-nothing constraint handler to be set.

> I do understand that you have concerns about the constraint handlers.  Got it.
> Would it be better if there were GNU extensions for the Annex K functions
> that guaranteed to *not* call the constraint handler ("NAME_s_e")?

No, this would be yet another layer of utter crap functions on top of
a layer of utter crap functions. There are many 3 or 4 "useful"
functions out of the whole annex K (the main one being qsort_s) and
the rest is just utterly redundant and not useful for the stated
purpose (of making software more secure). And for some of them,
implementing them imposes ugliness and potential bugs on other core
functions unless you want completely redundant implementations -- for
instance, the scanf core needs additional code to support the annex K
scanf-family functions, specifically the ugly double-argument forms
for %s, %c, and %[, and these are then incompatible with the POSIX
i18n %N$ argument reordering.

Rich