[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87wolfm56s.fsf@oldenburg2.str.redhat.com>
Date: Mon, 04 Mar 2019 09:09:31 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
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.
Thanks,
Florian
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.
