Re: Implement C11 annex K?

["David A. Wheeler" <dwheeler at dwheeler dot com>]

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?


> > 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.


> ... 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.  Indeed, I think that should be the default.  Libraries have to
assume that the constraint handler allows returns, by spec.

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")?
The "_s" functions could then be implemented by calling these other functions.
I haven't looked into how practical that is, but it's probably do-able.
That would at least give you a way to guarantee avoiding the constraint
handler, if desired, and it would implemented the functions as defined in the standard.

--- David A. Wheeler