Variadic functions

[Christopher Benson-Manica]

Do variadic functions (such as printf()) always scan the format string
for format specifiers, even when there are no additional arguments?
If it is instead a QoI issue, what would be true for a typical
implementation?

Basically, I'm wondering whether there is any advantage to using
puts() instead of printf() for output of a string.

 

[Andrey Tarasevich]

Do variadic functions (such as printf()) always scan the format string
for format specifiers, even when there are no additional arguments?
If it is instead a QoI issue, what would be true for a typical
implementation?

Basically, I'm wondering whether there is any advantage to using
puts() instead of printf() for output of a string.

In general case functions have no means to determine how many arguments
was supplied in the call. In other words, the situation "when there are
no additional arguments" is not detectable from inside of the function,
which means that the function has no other choice but to scan the format
string and try to retrieve the variadic parameters (if format string
directs it to do so). If there were no actual arguments in the call, the
behavior is undefined.

 

[Gordon Burditt]

Do variadic functions (such as printf()) always scan the format string

for format specifiers, even when there are no additional arguments?

There is no standard way for a varadic function to know how many
arguments it actually got. Now, printf() *COULD* be implemented
with compiler magic, but I can't see where this particular optimization
is worth doing. And printf() would STILL have to translate %% in
the format string to % in the output.

If it is instead a QoI issue, what would be true for a typical
implementation?

In a typical implementation, printf() does not know how many arguments
it actually got, and the way it tells how many arguments it's
supposed to have is to scan the format string.

Basically, I'm wondering whether there is any advantage to using
puts() instead of printf() for output of a string.

printf(string) and puts(string) are not equivalent. puts() adds a
trailing newline; printf() does not. printf(string) is downright
dangerous if string can contain arbitrary data obtained from input
that hasn't been screened for % characters (funny input can make
the program smegfault). printf("%s\n", string) is equivalent to
puts(string) when the return value is not used, but this doesn't
involve invoking printf() with no arguments beyond the format string.

Any program can run infinitely fast if it's acceptable for it to
give the wrong (no) result.

Gordon L. Burditt

 

[Dave Vandervies]

Do variadic functions (such as printf()) always scan the format string
for format specifiers, even when there are no additional arguments?
If it is instead a QoI issue, what would be true for a typical
implementation?

Mu. Barring implementation magic in printf, the only way it has to
tell that there are(should be) no additional arguments is to scan the
format string. In the general case, a variadic function needs to be
able to determine the availability and type of variadic arguments using
only information in the non-variadic arguments.

Basically, I'm wondering whether there is any advantage to using
puts() instead of printf() for output of a string.

puts() handles '%' in the string rather more nicely, by simply printing
it instead of invoking undefined behavior. It also appends a newline,
which may be undesirable.
If you can get away with not using printf *at all*, you can avoid bringing
the entire printf engine into your program. Using printf somewhere means
using it somewhere else has no additional size cost. Linking against
dynamic libraries will make this potential benefit irrelevant.
Using printf will have a penalty of maybe a few cycles per character
for strings that don't contain any '%'. With the additional cost of
actually moving the characters between the program and whatever stdout
is connected to, there's no way you'll ever notice this cost, no matter
how many characters you're printing.

printf("%s\n",str) behaves exactly the same as puts(str). If the trailing
newline is undesirable and str may contain '%', you want printf("%s",str).


dave

 

[pete]

Do variadic functions (such as printf()) always scan the format string
for format specifiers, even when there are no additional arguments?
If it is instead a QoI issue, what would be true for a typical
implementation?

Basically, I'm wondering whether there is any advantage to using
puts() instead of printf() for output of a string.

K&R2, section 7.7, page 156,
shows a function definition for minprintf().
It should give you some idea of the logic invlolved.
The logic of puts is relatively simple.

In my toy library, I have put_s like this:

#include <stdio.h>
#define put_c(c, stream) (putc((c), (stream)))
#define put_char(c) (put_c((c), stdout))

int put_s(const char *s)
{
while (*s != '\0') {
if (put_char(*s) == EOF && ferror(stdout) != 0) {
return EOF;
}
++s;
}
return put_char('\n');
}

My min_printf is like this:

#include <stdarg.h>

#define fsput_char(c) \
(put_char(c) == EOF && ferror(stdout) != 0 ? EOF : 1)

static int fsput_s(const char *);
static int fsput_u(unsigned);
static int fsput_u_plus_1(unsigned);
static int fsput_d(int);

int min_printf(const char *s, ...)
{
int count, increment;
va_list ap;

va_start(ap, s);
for (count = 0; *s != '\0'; ++s) {
if (*s == '%') {
switch (*++s) {
case 'c':
increment = fsput_char(va_arg(ap, int));
break;
case 'd':
increment = fsput_d(va_arg(ap, int));
break;
case 's':
increment = fsput_s(va_arg(ap, char *));
break;
case 'u':
increment = fsput_u(va_arg(ap, unsigned));
break;
default:
increment = fsput_char(*s);
break;
}
} else {
increment = fsput_char(*s);
}
if (increment != EOF) {
count += increment;
} else {
count = EOF;
break;
}
}
va_end(ap);
return count;
}

static int fsput_s(const char *s)
{
int count;

for (count = 0; *s != '\0'; ++s) {
if (put_char(*s) == EOF && ferror(stdout) != 0) {
return EOF;
}
++count;
}
return count;
}

static int fsput_u(unsigned integer)
{
int count;
unsigned digit, tenth;

tenth = integer / 10;
digit = integer - 10 * tenth + '0';
count = tenth != 0 ? fsput_u(tenth) : 0;
return count != EOF && put_char(digit) != EOF ? count + 1 : EOF;
}

static int fsput_u_plus_1(unsigned integer)
{
int count;
unsigned digit, tenth;

tenth = integer / 10;
digit = integer - 10 * tenth + '0';
if (digit == '9') {
if (tenth != 0) {
count = fsput_u_plus_1(tenth);
} else {
count = put_char('1') == EOF ? EOF : 1;
}
digit = '0';
} else {
count = tenth != 0 ? fsput_u(tenth) : 0;
++digit;
}
return count != EOF && put_char(digit) != EOF ? count + 1 : EOF;
}

static int fsput_d(int integer)
{
int count;

if (0 > integer) {
if (put_char('-') == EOF) {
return EOF;
}
count = fsput_u_plus_1(-(integer + 1));
return count != EOF ? count + 1 : EOF;
} else {
return fsput_u(integer);
}
}

 

[Dan Pop]

Do variadic functions (such as printf()) always scan the format string
for format specifiers, even when there are no additional arguments?
If it is instead a QoI issue, what would be true for a typical
implementation?

The only source of information WRT the number and type of arguments for
printf and friends is the format string. It is OK to pass them more
arguments than specified by the format string (they will ignore them)
but it invokes undefined behaviour to pass them fewer arguments.

Basically, I'm wondering whether there is any advantage to using
puts() instead of printf() for output of a string.

Yes: puts doesn't have to scan the string (except for finding
the terminating null character) and you don't have to tread the %
character in a special way. As an added bonus, it also appends a
free newline at the end of the string (use fputs if you don't want it).

OTOH, the program is (slightly) more readable if printf is the only
output function being used.

However, both pro and con arguments are extremely weak, so use whatever
you feel as the most appropriate to the context.

Dan