Having just seen another source-changes message go by about printf,
%q, and int64_t (on the Alpha, %q isn't correct for int64_t, of
course), I wonder if there's room for a different tack on extended
printf formats.

Microsoft C uses, if I recall correctly, %I64 to print a 64-bit
integer (capitalized so it is properly in the vendor-reserved
extension range), and I *think* a corresponding %I32.  This
conveniently matches the __int64 and __int32 datatypes they offer, so
that if you use (or cast to) those types, you can trivially match the
printf format.  On the other hand, I personally loathe the 8-bit
centrism implicit in exposing a set of bit-widths (even though there
probably will never again be a 9 or 10 bit byte), and that still
doesn't solve the desire to print things like off_t or fseek_t without
admitting explicitly how long they are (and, of course, there's always
the possibility that a given program will outlive the 64-bit limit and
become embarrassed when off_t requires %I128...).

Perhaps, though, at least the popular typedef'd types could use the
same kind of extension mechanism; %Ioff_t for off_t (however wide your
compilation system make it), %Isize_t, and so on.  (You can either
limit it to the "_t" types, or explicitly terminate the name with ' or
something, or use the ugly string-concatenation hack that's used to
get around the lack of explicit termination for \x (i.e. "\xaa" "aa"
to avoid generating the "character" \xaaaa).)

Unfortunately, if you don't do all the system supplied types, users
have to constantly refer to the manual to figure out which types are
supported and which aren't; if you resolve to do all the system
supplied types, you have to update printf.c (and friends) every time
you add a new type, PLUS you encourage users to whine about it not
working for THEIR typedefs as well.

Well, it's an idea, for contemplation the next time someone has to
kill half a day adjusting printf formats and wishing there was a
better way...

Thank goodness C++ solves this problem.  Mostly.