From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12549 Path: news.gmane.org!.POSTED!not-for-mail From: Jens Gustedt Newsgroups: gmane.linux.lib.musl.general Subject: Re: Header conformance/improvements (part 2) Date: Sun, 25 Feb 2018 09:07:05 +0100 Organization: inria.fr Message-ID: <20180225090705.31a21fe6@inria.fr> References: <20180223192049.GI1436@brightrain.aerifal.cx> <20180225001745.GM1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/OA7Xlkp=f82AnAgtWvgFnl6"; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1519545920 9763 195.159.176.226 (25 Feb 2018 08:05:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Feb 2018 08:05:20 +0000 (UTC) Cc: musl@lists.openwall.com Original-X-From: musl-return-12565-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 25 09:05:16 2018 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.84_2) (envelope-from ) id 1eprJ5-00021O-8G for gllmg-musl@m.gmane.org; Sun, 25 Feb 2018 09:05:15 +0100 Original-Received: (qmail 7967 invoked by uid 550); 25 Feb 2018 08:07:18 -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 7943 invoked from network); 25 Feb 2018 08:07:17 -0000 X-IronPort-AV: E=Sophos;i="5.47,392,1515452400"; d="scan'208";a="315177975" In-Reply-To: <20180225001745.GM1436@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ Xref: news.gmane.org gmane.linux.lib.musl.general:12549 Archived-At: --Sig_/OA7Xlkp=f82AnAgtWvgFnl6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello Rich, On Sat, 24 Feb 2018 19:17:45 -0500 Rich Felker wrote: > > > I don't think this is any actual diference; the const keyword is > > > a nop there. Issue 844 is just about the standard gratuitously > > > including a do-nothing keyword there. =20 > >=20 > > Right. Keeping the qualifier here is harmless. =20 >=20 > Oh, I read it backwards and thought we lacked the const. I'm in favor > of removing redundant/meaningless stuff in declarations. BTW all > instances of __restrict except one or two (pointer-to-__restrict) are > also of this type; they're meaningless in the declaration and perhaps > should be removed. You are right concerning the validity of the interface, and I agree that the const should be removed. It contains no valuable information for the caller. The restrict information is different. Restrict is a important contract with the caller, and it is really a pitty that it cannot be enforced. Nevertheless compilers can (and should) diagnose violations of the restrict contract that it is able to deduce from the visible code. So I think such information should not be removed from interfaces. > > > Ah. This is problematic because functions declared in inttypes.h > > > require wchar_t to prototype. Of course a shadow name for the same > > > type can be defined (like how va_list is handled) but it's ugly... > > > =20 > [...] =20 > > > > > > Similar issue. It could be fixed with a shadot typedef or explicit > > > "struct _IO_FILE". The latter is ugly and something of a > > > violation of the abstraction, I think.. =20 > >=20 > > Indeed. I think ISO C should have exposed these data types. =20 >=20 > I agree. Maybe we should change it though. I'll think about it. I know > there were tests (I think gcc fixincludes mess) flagging spurious > exposure of va_list as a bug, and in principle someone might decide to > do the same here, but maybe we should wait to make any change until > if/when there's a problem. I agree, all C library header specifications in the standard should force all types of their interfaces exposed. I note that as a modification request for C2x, but I would not at all be sure that such a change would be consensual, and such a change would still be only in years to come. Thanks Jens --=20 :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/OA7Xlkp=f82AnAgtWvgFnl6 Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCWpJuqQAKCRAP0+hp2tU3 4oUMAKCWATvWYiUZa6BeisxTpTHxi5T4agCglPXOr6xghM5krdrlt3KGGjIU3eA= =NGR7 -----END PGP SIGNATURE----- --Sig_/OA7Xlkp=f82AnAgtWvgFnl6--