Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Hexadecimal Escape Sequence
Message-ID: <11964@smoke.BRL.MIL>
Date: 17 Jan 90 13:49:44 GMT
References: <1335@cybaswan.UUCP> <11960@smoke.BRL.MIL> <1990Jan16.194556.6727@utzoo.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 44

In article <1990Jan16.194556.6727@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Introducing, in return, a new deficiency:  the inability to terminate
>the hex sequence simply and cleanly when desired.  Don't think this
>wasn't pointed out during the public reviews, by me among others.

>>The simplest method is to use string concatenation:
>>	printf("\x1b""fred");

>As the man said, "there's *got* to be a better way".  Unfortunately, none
>made it into the standard.  Using string concatenation for this is an
>ugly kludge, not a proper solution.  The right way would have been to
>include some sort of bracketing as part of the escape, e.g. "\x(ab)".
>This would even have allowed compatibility with C++ and other prior art:
>length is unlimited only within brackets, with plain "\xabc" being limited
>to three digits like the octal escapes.

I bet you couldn't get agreement on whether that should be three or two.
And people with 16-bit chars would be pissed off at either choice.

The only alternative I recall X3J11 voting one was one that I proposed,
namely that the number of hex digits glommed onto after \x would be
implementation-defined.  I don't recall a bracketed notion being voted
on or even proposed.  (I would slightly prefer \xabx over \x(ab).)

The behavior actually adopted has the merits of being simple to specify
and being interpreted the same in all implementations (up to
representation overflow).

Besides, all you need do is think of ""\x and "" as being the actual
brackets, if you want a uniform method.  "foo""\xab""bar"

>Alas, it's too late now.  I expect the result will be widespread aversion
>to the error-prone context-sensitive hex escapes, defeating the original
>purpose of making life easier.

They don't seem particularly error-prone to me, because the idea of
embedding character code values in string literals is highly
nonportable, so I'm unlikely to do it anyway.  About the only way I'd
use these would be to have something like the following in a system
configuration file:
	#define	CSI	"\x1b["	/* control string introducer */
	#define	ACK	'\x06'	/* ACKnowledge successful receipt */
and there it would be pretty simple to remember to think about what
I'm doing with the \x notation.