This only applies to a very limited kind of error handling. How would
you use it to report a syntax error in user input for example?
User-input errors are easy to reproduce and test, so I would have no
quarrel with a sophisticated varargs thingy to print out a detailed
description of a syntax error.
Whether the remainder is "very limited" depends on the nature and
requirements of what you're doing. At the very least, I would
encourage people who choose to use a varargs error reporting thingy to
either use printf or fprintf directly, or to use their favorite
compiler's printf-like attribute (if available) on their custom error
reporting function so that lame argument mismatches don't crash your
program before you can even print the message.
For a more rigorous environment, combine that with some defensive
coding like implementation-specific checks on pointer locations, fflush
log files char by char (or setbuf), stop processing the va_arg list on
the first NULL or bad pointer, don't include any pointed-to data in
output unless all pointers pass the sanity checks, print and fflush the
constant part of the error message before processing dodgy arguments,
check pointers to strings (including the format string) to see if they
have non-printable chars or are more than 80 characters, and log the
date and time of the message, maybe even __FILE__ and __LINE__. Check
for low addresses on things passed in by value: the int you get might
be coming from something like (NULL)->struct.value. Check aligment
while you're at it. In environments which exceed the scope of ANSI C,
also consider printing out things like the thread number. Finally,
*test* the error reporting function by giving it deliberately garbaged
data of all kinds and make sure it doesn't choke.
Sure, this is overkill for a lot of programs, but if this makes the
difference between a truncated/garbaged log file and something that
helps you diagnose and fix a problem on a server in Kreplakistan at
3:00AM on Saturday night, you won't regret it.