From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13917 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: C Annex K safe C functions Date: Mon, 04 Mar 2019 09:09:31 +0100 Message-ID: <87wolfm56s.fsf@oldenburg2.str.redhat.com> References: <20190227131153.GT23599@brightrain.aerifal.cx> <20190227163420.GU23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="223956"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13933-gllmg-musl=m.gmane.org@lists.openwall.com Mon Mar 04 09:09:51 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1h0ifW-000wAH-Ms for gllmg-musl@m.gmane.org; Mon, 04 Mar 2019 09:09:50 +0100 Original-Received: (qmail 13324 invoked by uid 550); 4 Mar 2019 08:09:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 12277 invoked from network); 4 Mar 2019 08:09:47 -0000 In-Reply-To: <20190227163420.GU23599@brightrain.aerifal.cx> (Rich Felker's message of "Wed, 27 Feb 2019 11:34:20 -0500") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 04 Mar 2019 08:09:35 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:13917 Archived-At: * 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