From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13921 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: C Annex K safe C functions Date: Tue, 5 Mar 2019 14:19:42 +0100 Message-ID: <20190305131942.GA26605@port70.net> References: <20190227131153.GT23599@brightrain.aerifal.cx> <20190227163420.GU23599@brightrain.aerifal.cx> <87wolfm56s.fsf@oldenburg2.str.redhat.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="227899"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13937-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 05 14:20:00 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 1h19zD-000x8Y-6H for gllmg-musl@m.gmane.org; Tue, 05 Mar 2019 14:19:59 +0100 Original-Received: (qmail 3842 invoked by uid 550); 5 Mar 2019 13:19:55 -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 3806 invoked from network); 5 Mar 2019 13:19:54 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <87wolfm56s.fsf@oldenburg2.str.redhat.com> Xref: news.gmane.org gmane.linux.lib.musl.general:13921 Archived-At: * Florian Weimer [2019-03-04 09:09:31 +0100]: > * 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. well microsoft did lobby for the _s functions originally, the msvc library team is likely responsible for the concept. it turned into tr 24731 and eventually annex k in c11, by that time microsoft may not have much to do with it. one can dig through wg14 to see how it evolved. initial work: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1007.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1031.pdf a tr 24731 meeting (ms is still involved): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1129.pdf some tr 24731 drafts: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1088.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf austing group comments: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1106.txt http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1160.pdf responses: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1118.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1174.pdf tr 24731 rationale: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1173.pdf c1x inclusion: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1350.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1394.pdf