From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6671 Path: news.gmane.org!not-for-mail From: Rich Felker 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 09:47:01 -0500 Message-ID: <20141203144701.GJ4574@brightrain.aerifal.cx> 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 1417618043 28451 80.91.229.3 (3 Dec 2014 14:47:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 14:47:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6684-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 03 15:47:18 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 1XwBD1-00020I-5A for gllmg-musl@m.gmane.org; Wed, 03 Dec 2014 15:47:15 +0100 Original-Received: (qmail 3625 invoked by uid 550); 3 Dec 2014 14:47:13 -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 3611 invoked from network); 3 Dec 2014 14:47:13 -0000 Content-Disposition: inline In-Reply-To: <1417602004.4936.1233.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6671 Archived-At: On Wed, Dec 03, 2014 at 11:20:04AM +0100, Jens Gustedt wrote: > 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 > > > > I don't see where your interpretation is clear from these. DR 209 > > added the text I cited. It's not clear what the change made to > > 7.18.4.1 is (I don't have the old text in front of me) so perhaps you > > could shed some light on why you think it requires the odd types. > > I also only have the corrected version in front, but I vaguely > remember that the change was from types [u]intXX_t to [u]int_leastXX_t > because the macros are supposed to exist, even if the corresponding > [u]intXX_t doesn't. > > > 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. > > 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. If you have access to discussions that aren't public, could you try to get the GCC folks in on them? GCC's stdint.h agrees with my interpretation and I don't think it's useful to flip back and forth between interpretations or make more incompatible ones. We should be aiming to get a real understanding of what the intended requirement is, whether there's consensus on implementing that, and what needs to be done to get things right. Obviously my preference is to keep things the way GCC and musl is doing, but if WG14 would spell out explicitly that this is wrong (and hopefully get GCC and others to listen), I'm fine with changing it. > 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. No, consider things like UINT64_C(42). Simply using 42 or 42U would have the wrong type, which matters for passing arguments to variadic functions that expect uint64_t, use with sizeof, etc. Of course you could just cast, as in (uint64_t)42, but that loses the "promotions" aspect of the macros. I don't see why the macros would even exist if this were the intent, since casts work just as well if not better. The added value of the macros is that they give you the right promoted type when it matters, but of course you could also get this via something like +(uint8_t)42, so IMO the macros are utterly useless and there's no reason for any code to be using them or depending on which behavior they have. Rich