Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.lang.c Subject: Re: Value of x? Message-ID: <5712@brl-smoke.ARPA> Date: Tue, 31-Mar-87 14:47:54 EST Article-I.D.: brl-smok.5712 Posted: Tue Mar 31 14:47:54 1987 Date-Received: Sat, 4-Apr-87 08:42:40 EST References: <6570@brl-adm.ARPA> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 21 In article <6570@brl-adm.ARPA> @relay.cs.net> writes: >C Guri: >In the Microsoft C compiler V4.0, '\x' is compiled as 0 on the >grounds that it's a brain-damaged version of '\x00'. This is what >Microsoft's support group said when I reported what I thought was a >bug. I claim that '\x' is a perfectly fine representation of the >character x and should have value 120 base 10. How sayeth INFO-C? Future ANSI-conforming C compilers will treat '\xNNN' (where NNN are 1 to 3 hexadecimal digits) as the hex code for a character. '\x' is not supposed to be a valid hex code, but we don't say what it is; definitely it's not guaranteed to be just the letter 'x'. By the way, I intend to submit an improved proposal for removing the limit to the number of bits supported for \x. The one I presented at the very end of the last meeting ran into at least one valid objection (I had also proposed extending the \0 constants, which can cause problems with existing code that uses embedded NULs). So, basically, MicroSoft is right, except it would be nicer if they would diagnose the case of missing NNN after the \x.