From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Booth To: Zack Weinberg Cc: Frank Klemm , gcc@gcc.gnu.org Subject: Re: Proposal Date: Wed, 19 Sep 2001 00:02:00 -0000 Message-id: <20010919080220.B19239@daikokuya.demon.co.uk> References: <20010917235928.A11347@daikokuya.demon.co.uk> <20010918102000.D3510@codesourcery.com> <20010918211231.A21191@fuchs.offl.uni-jena.de> <20010918223652.J12089@codesourcery.com> X-SW-Source: 2001-09/msg00748.html Zack Weinberg wrote:- > Let's get back to what you originally proposed. You want to be able > to write 1000000 as 1_000_000 for legibility. This would be easy to > implement and I agree that it would be an improvement. What you need > to do is decide exactly what the extended syntax is supposed to be. > For instance, are you allowed to write any of the following? > > 16777216_UL [1] > 16777216U_L [2] > 0._1234 [3] > 0x_1234 [4] > 12.34_e+56 [5] > 12.34e_+56 [6] > > All but the last are legitimate "preprocessing numbers". I can tell > you right now that I'll be a lot more receptive to an extension that > doesn't change the definition of a preprocessing number. I don't think we want to accept anything that changes the pp-number definition; I consider it set it stone. I've labelled your examples above. [6] is not a pp-number, so I'd rule it out from the start. For the rest, I see two reasonable things to say: 1) A pp-number with '_' in it is interpreted as if all '_' were stripped out initially. 2) We allow _ only in the integer part of decimals / hex / floats, but anywhere and anyhow in those parts. Not valid in suffixes. Interpreted as if the '_' were stripped out. This would invalidate [2], [3] and [5]. Anything more complex is probably not worth it. 1) is appealling merely because it is simple and unambiguous. Neil.