From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6668 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 3/4] use exact types for the [U]INTXX_C macros Date: Wed, 3 Dec 2014 14:21:55 +0100 Message-ID: <20141203132155.GD9258@port70.net> References: <1416926886.16006.925.camel@eris.loria.fr> <20141202180355.GD29621@brightrain.aerifal.cx> <1417548001.4936.1106.camel@eris.loria.fr> <20141202194435.GG29621@brightrain.aerifal.cx> <1417556274.4936.1130.camel@eris.loria.fr> <20141203000132.GA4574@brightrain.aerifal.cx> <1417602004.4936.1233.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1417612934 1091 80.91.229.3 (3 Dec 2014 13:22:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 13:22:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6681-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 03 14:22:09 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xw9se-0008Jh-Vg for gllmg-musl@m.gmane.org; Wed, 03 Dec 2014 14:22:09 +0100 Original-Received: (qmail 7325 invoked by uid 550); 3 Dec 2014 13:22:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7314 invoked from network); 3 Dec 2014 13:22:07 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <1417602004.4936.1233.camel@eris.loria.fr> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6668 Archived-At: * Jens Gustedt [2014-12-03 11:20:04 +0100]: > Am Dienstag, den 02.12.2014, 19:01 -0500 schrieb Rich Felker: > > On Tue, Dec 02, 2014 at 10:37:54PM +0100, Jens Gustedt wrote: > > > These are DR 209 and 456 > > > > > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_209.htm > > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1892.htm#dr_456 > > > > DR 456 just seems to state that DR 209 already adequately handled the > > situation and that no further change is needed. > > exactly, furthermore they add > > The committee believes that DR209 is still appropriate in that > "compiler magic" must be used for the implementation of these > macros. The committee does not consider this a defect. > > The part about the compiler magic is completely senseless when > supposing that the constants promote. > i read dr 456 and even the meeting minutes when this came up on comp.std.c https://groups.google.com/forum/#!msg/comp.std.c/6wIA_XDhOwU/x_859JqaKBMJ and it still does not make sense to me: somehow 'type' of the expression is interpreted in preprocessor context eventhough integer promotion makes no sense there and there is a clear contradiction between "The type of the expression shall have the same type as would an expression of the corresponding type converted according to the integer promotions." and "The macro INTN_C(value) shall expand to an integer constant expression corresponding to the type int_leastN_t." the 'promotion' part is missing from the later and neither says what to do with the types in the preprocessor it would be much better if wg14 had a public discussion (similar to the austingroup mailing list) where such nonsense could be clarified > In addition, from discussion on the WG14 mailing list I see that > people there expect the macros to resolve to the unpromoted type when > used in _Generic. > > And isn't all of this just the purpose of these macros? If we'd > suppose they promote, standard literals to denote the constants would > mainly suffice: they already do the right thing for narrow types, > namely promotion. getting constants with unpromoted type makes sense, but then the text should say that and have a separate well defined requirement for the preprocessor