Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 04 Mar 2019 09:09:31 +0100
From: Florian Weimer <>
To: Rich Felker <>
Subject: Re: C Annex K safe C functions

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


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.