C11 Annex K support

[Szabolcs Nagy]

On 16/01/2019 16:59, Manfred 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:
> 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

the annex k functions depend on writable global state
that cannot be set safely in a multi-thread process.
that alone makes them unsuitable for inclusion into
a c runtime.

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

i think snprintf is the recommended api for most
string manipulation code that needs checks for
destination buffer size.

it is in the c99 standard and thus widely supported.