Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: "%#s"?
Message-ID: <4311@haddock.ISC.COM>
Date: 31 May 88 22:47:30 GMT
References: <AWbStey00Uk4E0S14d@andrew.cmu.edu> <1988May28.222450.2680@utzoo.uucp> <19166@watmath.waterloo.edu> <1039@cresswell.quintus.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 34

In article <1039@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <19166@watmath.waterloo.edu>, rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes:
>> Perhaps %#s and %#c can be added in future updates to the language.
>
>In the mean-time, why not post sources for a
>	spr_str(char *buffer, int width, int places, char *source)

Since the result is probably going to be handed to printf anyway, I'd get rid
of the width/places arguments and let printf handle them.  This keeps the
function simpler.  (It would, however, probably be a good idea to add a size_t
argument representing the buffer size, to protect against overflow.  Why
repeat sprintf's mistake?)

>spr_str(buf, width, 1, &c) can serve for sprintf(buf, "%#*c", width, c).

Not if c is declared register and/or int (both of which are common when
dealing with text).  I think this case is sufficiently useful and simple that
it deserves to be a separate function: char *spr_chr(int c); the buffer itself
can be static.  (One might also include EOF in the domain.)

This still leaves some questions.  What should be the specifications for the
output of these functions?  In particular, on an ASCII system, should
spr_chr('\1') return "\\1", "\\001", "\\x01", "\\x1\\c", "\\^A", or "^A"?
Should spr_chr('\10') return "\\b"?  What about spr_chr('\\'), does it behave
like other printing chars and return "\\" (that's a string of length 1), or do
we want the output to be completely unambiguous, and return "\\\\" (that's two
backslashes)?

I find that in practice, the answers to the above depend on the application,
which is why I haven't yet installed this function in my private library.
(Also, I'm waiting to see if X3J11 resolves the problem of terminating hex
constants, as it may influence the design decision.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint