My reaction to this is "not using punched cards makes it hard to port
to (other) legacy systems". The point beyond which a system is so
legacy it's not worth even trying to support it, for me, includes
systems without calls like snprintf.
> It's still not clear to me why people only suggest snprintf(). I
> would imagine that there are only a few cases were a program coulnd't
> pre-determine the length of a string that would be generated by
> sprintf() and malloc() enough memory to contain it all.
Probably, yes, since the whole *printf() family exists in
full-source-available forms, so any program can just haul in the whole
thing, it can figure out the total length.
> Yes, it's a little extra work to strlen() all the variables you're
> pulling in, but you ensure that you have a large enough buffer, you
> eliminate the buffer overflow problem, and you don't truncate the
> string.
You also can't handle anything but strings that way (there's no a
priori way to tell how many characters something like %d can take up,
though admittedly (CHAR_BIT*sizeof(int)/3)+2 is a reasonable maximum),
and you're assuming whatever the result will be fed to can handle an
arbitrarily large string.
> Is malloc()-ing the memory *that* inefficient? Less efficient than
> the scanning and parsing snprintf() must do to the format string?
You're going to have to do the scanning and parsing _anyway_ in order
to do the "printing", so there's no call to compare that cost against
anything.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B