Path: utzoo!utgpu!water!watmath!rbutterworth
From: rbutterworth@watmath.waterloo.edu (Ray Butterworth)
Newsgroups: comp.lang.c
Subject: Re: Hex escapes in strings
Message-ID: <16646@watmath.waterloo.edu>
Date: 1 Feb 88 17:12:39 GMT
References: <2938@zeus.TEK.COM> <7021@brl-smoke.ARPA> <886@micomvax.UUCP>
Organization: U of Waterloo, Ontario
Lines: 30


I too think that allowing arbitrarily long hex strings is not
a good idea, though not for the same reason.

Something that I've always felt should be in the standard printf
functions is allowing the "#" qualifier for %c and %s formats.

"%#c" would print the character as an appropriate escape sequence
if it wasn't a printing character.
(hex vs. octal would be implementation dependent)
e.g. \n, \f, \001, \0xff.

This would make error messages a lot easier to read.
Typically they now say either "Illegal character '%c'\n", or
"Illegal character %#o\n".  The first is very ugly and unreadable
for non-printing characters, the second is unreadable for printing
characters if you haven't memorized the ASCII codes for '*', '}',
etc.  Using "%#c" would give the correct version every time.

Similarly, "%#s" would perform this same expansion on strings.
printf("%#s\n", "one\ntwo");
would produce a single 8 character line of output: "one\ntwo".

If ANSI allows arbitrarily long hex sequences, this scheme
cannot be implemented, since there is no way to indicate
the end of a hex sequence, and so "%#s" output could be
ambiguous.

The previously mentioned suggestion of a null-escape, e.g. "\z",
that did nothing, would solve the problem.