Re: C Annex K safe C functions

[Florian Weimer <fweimer@redhat.com>]

* Rich Felker:

> 5. Expanding on the topic of FUD/misinformation, both the introduction
> of the original *_s functions, and lobbying for their inclusion in the
> standard (which eventually reached the compromise of just putting them
> in an Annex), was not about improving the C language or making useful
> tools for programmers, but about introducing incompatibility and
> fragmentation to the language/standard with the goal of undermining
> it. The company that introduced it produces a product that is not
> compatible with the C language as specified and does not even aim to
> be, but aims to give the impression of being a C implementation (it's
> mainly a C++ implementation, though likely not conforming to that
> standard either).

Does this really reflect history?  I thought that Annex K was submitted
for standardization well after the vendor in question withdrew from the
ISO process.

> It's my position, and I believe it's shared by many others in the musl
> community and C language communities, that parties not interested in
> implementing or using the standard should not try to influence its
> direction, and that this kind of behavior should not be rewarded by
> playing along with it, but that it should be shunned as long as doing
> so is practical.

My impression is that compiler vendors and large-scale users are
generally not well-represented in the ISO process anyway.  If true, your
requirement, while looking completely reasonable, would effectively halt
evolution of the standard.

Thanks,
Florian