"%#s"?

[Karl Heuer]

In article <1156 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP (der Mouse) writes:
>In article <4311 at haddock.ISC.COM>, karl at haddock.ISC.COM (Karl Heuer) writes:
>>[The routine to unctrl a single character can use a static buffer]
>
>If you are going to use a static buffer, folks, please use several of
>them, or otherwise arrange that it doesn't lose big if I [call the function
>twice in one expression]

If I could be certain that the domain would be small, I'd go with the lookup
table you suggest.  But we need to decide what properties are guaranteed to be
true, even on (say) an implementation with 16-bit chars.  (Remember, this
started out as something that was proposed for the ANSI standard.)

If we say that the return pointer is always valid, we are effectively
requiring the implementation to reserve 2*^CHAR_BITS of these strings in
memory.  This could be quite a bit of space; I don't think it's practical.

We could use the heap, but then the user would have to be responsible for
freeing it (which means he must save the pointer, which is an inconvenience of
roughly the same magnitude as providing his own buffer).  Also, this would
necessitate an error return, in case malloc fails.

Maybe the best way is to provide two char-viewing routines.  One would expect
the user to pass a buffer, and would be analogous to the string-viewing
routines.  The other would use a single static buffer, with the usual caveat.

What a mess.  Implementing it as a printf format would avoid all of this.

>(by the way, is the chr==(int)(unsigned char)chr test a safe way of
>testing whether the value is one an unsigned char could take on?)

Yes, but "(unsigned)chr <= UCHAR_MAX" might be better.

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