Re: Implement C11 annex K?

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

On 13-08-2014 16:23, 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?

>From time to time it arises and there is small FAQ about it [1].  Bottom line: it is not
consensus that the strlcpy/strlcat functions provides any more 'safety'.  You can check
glibc alpha history and there are number of cases saying that it does not in fact, this is
just and example [2]. 

I personally see compiler driver directives (like -D_FORTIFY_SOURCE or ASAN), runtime
checks (like valgrind), or even higher level languages constructs (like std::string) to
provide safety in a much more clean way. But I no expert in security...

[1] https://sourceware.org/glibc/wiki/FAQ#Why_no_strlcpy_.2BAC8_strlcat.3F
[2] https://plus.google.com/u/0/+DavidHerrmann/posts/DGMdzUG3nyj


>
> 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")?

I don't see it a better way to do this.  The initial aim is to provide an optional
C11 annex, now the aim is to provide extension (that would be probably exported)
that might create even more non-portability.


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