From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 33b8ea89 for ; Fri, 27 Jul 2018 10:49:48 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1fj4zx-000328-OP; Fri, 27 Jul 2018 17:49:47 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1fj4zw-00071x-Lk; Fri, 27 Jul 2018 17:49:44 +0200 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1fj4zy-0005T0-6v; Fri, 27 Jul 2018 17:49:46 +0200 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 900ca3c2; Fri, 27 Jul 2018 17:49:44 +0200 (CEST) Date: Fri, 27 Jul 2018 17:49:44 +0200 From: Ingo Schwarze To: maya@netbsd.org Cc: tech@mandoc.bsd.lv, jmc@openbsd.org, guenther@openbsd.org Subject: Re: -isoC-2017 patch Message-ID: <20180727154944.GA49161@athene.usta.de> References: <20180727134915.GB28956@homeworld.netbsd.org> <20180727142326.GD18208@athene.usta.de> <20180727150204.GA13761@homeworld.netbsd.org> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180727150204.GA13761@homeworld.netbsd.org> User-Agent: Mutt/1.8.0 (2017-02-23) Hi Maya, maya@netbsd.org wrote on Fri, Jul 27, 2018 at 03:02:04PM +0000: > On Fri, Jul 27, 2018 at 04:23:26PM +0200, Ingo Schwarze wrote: >> https://www.iso.org/standard/74528.html >> >> seems to indicate the existence of a brand new standard called >> >> ISO/IEC 9899:2018 >> Information technology -- Programming languages -- C >> >> but i failed to find any evidence that an official standard >> called ISO/IEC 9899:2017 might exist. >> >> Can you provide a reference to such a standard? > I was reading > http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf Aha. That appears to be outdated. > which is a draft and unofficial, so yours is more correct. > (looks like a lot of s/17/18/ will have to be done elsewhere...) Possibly. >> Even if it does exist (or if you suggest s/17/18/), note that mandoc >> does not aim to provide macro arguments for all the standards under >> the sun. A new major revision of the C programming language is no >> doubt an excellent candidate for addition, but i would still welcome >> solid evidence that it will actually see substantial use in practice. >> >> Does the NetBSD base system implement the C18 standard, and are you >> going to update all the relevant NetBSD manual pages to refer to it, >> where appropriate? How many manual pages, approximately, do you >> expect will reference it in NetBSD in the short term? > There's not going to be many references to it That sounds like a strong argument to *not* add it. There is value in keeping programming languages small (including mdoc(7)) and avoiding the introduction of low-utility syntax. > like C11 After looking at the draft, it seems to me that there will likely even be fewer references to C18 than to C11, given that C11 did define a small number of new features, which at least in theory might get implemented and documented. > because it doesn't add new things, only makes changes to existing > stuff. I see. > I made the first reference to newer-than-C11 to document some change. I'm not sure i understand that sentence. You mean, so far, you committed one single change to one single NetBSD manual page (which one?) using the new macro argument, to document a change you committed to the NetBSD source code (which source code commit specifically?). > It's not critical, it just felt like the right change to do. Foc comparison, we decided to not add -p1003.1-2017 because it is not a new version of the standard but merely incorporates technical corrigenda into -p1003.1-2008. For the case of the C standard, if differences between C11 and C18 matter for a specific feature, i would consider recommending a wording like the following: The .Fn foobar function conforms to .St -isoC-2011 \" or -isoC-99 or -ansiC where appropriate including the corrections with respect to BARFOO applied by ISO/IEC 9899:2018 .Pq Dq ISO C18 . I expect such cases to remain rare. If it turns out they become very numerous, *that* would establish a reason to add a new macro argument. Does that make sense to you? Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv