On 12 January 2017 at 16:15, Richard Biener <rguent...@suse.de> wrote: > On Thu, 12 Jan 2017, Jakub Jelinek wrote: > >> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote: >> > > I'll give the (short) 1 parsing a try though to see how awkward it >> > > really gets. >> > >> > Ok, doesn't look a good way to go. Apart from making it difficult >> > to handle in the parser you can't distinguish a conversion from an >> > integer literal and a short literal for >> > >> > short s; >> > s_1 = (short) 1; >> >> As there are tons of types the integer literals can have, wouldn't it be >> better to just introduce _Literal <type, value> where you could supply >> the type if it is not one where C provides a suffix for it or int? >> Then we could avoid adding lots of suffixes for new and newer types. >> Of course for integer literals with int, unsigned int, {,unsigned} long >> {,long} >> one would still use no suffix, U, {,U}L{,L} suffixes. > > That's an interesting idea. _Literal (type) value might be alternative > syntax (a cast to be evaulated as literal). I'll give it a shot. Um, how about just type(value) ? s_1 = short (10); AFAIU this isn't legal C and could be added as an extension ?
Thanks, Prathamesh > >> > It looks like we currently have no way to write __int128 literals in C? >> > >> > __int128 x = 0xffffeeeeffffeeeeffffeeeeffffeeee; >> >> Yeah, one typically has to use >> __int128 x = (((unsigned __int128) 0xffffeeeeffffeeeeULL) << 64) | >> 0xffffeeeeffffeeeeULL; >> or something similar. > > I see. > > Thanks, > Richard.