Subject: Re: Linux's printf() extensions
To: None <email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 09/23/1998 15:44:16
>> Speaking as someone who basically reimplemented the guts of printf a
>> while ago, it would be nontrivial to do, and impossible in some
>> situations (for example, if $n is not used by the format, it's not
>> possible to handle $m correctly for m>n...unless certain
>> architecture-specific assumptions hold - assumptions which fail on
>> many current architectures).
> Um, in vfprintf, shouldn't that be perfectly plausible - after all,
> for a given %N$, you _should_ be able to assume that particular
> argument exists. If that means restarting the va_list and iterating
> through it, so be it.
Yeah, but the problem is, if some M<N is not referred to by the format,
you can't know what type to pass to va_arg to skip over it to get to
argument N. The "architecture-specific assumptions" which fail on many
current machines are basically that all argument types of interest are
the same size and passed in the same way and thus can be skipped
without caring about the type. The commonest way this fails today is
for arglist slots to be the size of an int, but for a double to take
two slots. That is, printf simply cannot correctly handle both
on such a machine. The SPARC is an example of such a machine. More
generally, other things are possible, such as pointers and non-pointers
being passed in, effectively, separate arglists, such that va_arg has
to consume an arg from the correct list in order to "work"...this is
why I said that if argument N is not used, then no argument M, M>N, can
be used, if it is to be possible for it to function correctly.
At least not without major rewriting of existing calling conventions.
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B