Path: utzoo!attcan!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond From: diamond@csl.sony.co.jp (Norman Diamond) Newsgroups: comp.lang.c Subject: Re: binary constants (??) Keywords: macro, constant, binary Message-ID: <11162@riks.csl.sony.co.jp> Date: 21 Nov 89 10:11:23 GMT References: <305@frf.omron.co.jp> <20830@mimsy.umd.edu> Reply-To: diamond@ws.sony.junet (Norman Diamond) Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan Lines: 31 In article <20830@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: >One of my favourite silly ideas for C is now ruled out by X3J11's >`#' `stringize' preprocessing operator (or at least, would require >some other syntax), but it went like this: Instead of having hex, >decimal, octal, binary, etc., constant syntaxes, why not have a >single syntax for `based numbers'? The initial radix would always >be decimal; the format would be something like > #(base,expr) >Numbers in the `expr' part would be interpreted in the base given by >the `base' expression. Any value from 2 to 36 would be legal for the >base. All `numbers' would be of the form > [0-9][0-9a-zA-Z]* The ISO Extended Pascal standard has numbers almost exactly like this. The syntax is base#expr, expr is of the form [0-9a-zA-Z][0-9a-zA-Z]*, and any value from 2 to 36 is legal for the base. "expr" must be a constant though, not really an expr. (base must be a constant too.) This could be added as an extension to C, except that if "expr" happens to match a formal parameter name in a macro expansion then the expr must be stringized instead. Alternatively, Mr. Torek's syntax could always be accepted as an extension, because #( is never legal in X3J11. (The processor would have to give a warning before accepting it. I think.) -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".