Re: Implement C11 annex K?

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

On 13-08-2014 16:43, Adhemerval Zanella wrote:
> 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

Some more interesting comments about [2]: https://plus.google.com/111049168280159033135/posts/1amLbuhWbh5