printf() with too many args -- legal? | Bytes (2024)

I know that passing printf() too few arguments, or arguments of the wrong
type invokes UB. However, what about passing too many arguments, if the
expected arguments are of the correct type?

For example:

char format1[] = "foo %s bar %s baz %d";
char format2[] = "foo %s bar %s no baz here";

char *strvar1 = "one", *strvar2 = "two";
int intvar = 123;

....

printf( some_condition ? format1 : format2, strvar1, strvar2, intvar );

When "some_condition " is false, printf() will expect two strings, but will
be passed two strings and an int.

Yes, I know this can be rewritten as:

if ( some_condition )
printf(format1, strvar1,strvar2 ,intvar);
else
printf(format2, strvar1,strvar2 );

However, this construct appears in numerous places throughout existing
code, which works on all current platforms it's ported to. I'd like to
make sure that it won't cause problems on some future platform.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer .h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

Subscribe Reply

Simon Biber <ne**@ralmin.cc > writes:

Kenneth Brody wrote:

Thanks. (And thanks to everyone else who answered.) I had a feeling
that that would be the case, but the *printf() functions seem to be
"special", in that the compiler can do type-checking at compile time
(given a literal format specifier), and I was afraid that there might
be some other "special" things about it.

They aren't special, from a language point of view. A standard C
compiler is not required to do type-checking of the variable arguments
of printf functions. The fact that some compilers do this is an extra,
non-standardised feature.

The *printf() functions are somewhat special in that they're part of
the standard library, so the compiler is allowed to make assumptions
about what they do. For example, a call like

printf("%d", 1.5);

invokes undefined behavior. The compiler is allowed to issue a
diagnostic (which is really beside the point, since a compiler may
issue a diagnostic for any reason at any time), but it's also allowed
to generate code that, for example, aborts the program rather than
calling printf(). And for a correct printf() call like:

printf("%s\n", "Hello, world");

the compiler may replace the printf() call with

puts("Hello, world");

It wouldn't be allowed to do these things for a user-defined
my_printf() function with the same prototype, *unless* it's able to
determine at compilation time (or at link time) how the user-defined
function actually behaves. For functions in the standard library, the
compiler is allowed to make these assumptions without analyzing the
implementation of the function, because the behavior is guaranteed by
the standard.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Richard Tobin wrote:

In article <42**********@s pool9-west.superfeed. net>,
Stan R. <st*********@br emove.lz.hmrpri nt.com> wrote:

Going out on a limb here, but has anyone ever written (for practical
use) a function that /actually/ /took/ 127 args?!?!?! (I almost
cringe at the though of a function declaration taking up half a
page! :-P )

Even 31 seems big for an arg list!

Some graphical interfaces have used vararg/stdarg argument lists with
alternating name-value arguments, and these can quite reasonably be
fairly long, though more than 30 arguments would be unusual even for
this case.

Good point, but the arg lists in a case like you described doesn't need
to be so long.

a) Encapsolate the name-value pair to a struct or class, and pass
instances of the struct instead (cutting the arg list in half. Or...

b) Cut it down to one arg by using something of the sort of a linked
list, thus just passing the first pointing, and the function keeps going
until it hits the NULL (end.)

c) not having used c for some time (been using c++ for year now after
using c for a while), I honestly can't remebmer if there are classes,
but iff you, one could write a Map or Hash type class, or just use
<map.h> :-)

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

"Stan R." <st*********@br emove.lz.hmrpri nt.com> writes:

Richard Tobin wrote:

In article <42**********@s pool9-west.superfeed. net>,
Stan R. <st*********@br emove.lz.hmrpri nt.com> wrote:

Going out on a limb here, but has anyone ever written (for practical
use) a function that /actually/ /took/ 127 args?!?!?! (I almost
cringe at the though of a function declaration taking up half a
page! :-P )

Even 31 seems big for an arg list!
Some graphical interfaces have used vararg/stdarg argument lists with
alternating name-value arguments, and these can quite reasonably be
fairly long, though more than 30 arguments would be unusual even for
this case.

Good point, but the arg lists in a case like you described doesn't need
to be so long.

a) Encapsolate the name-value pair to a struct or class, and pass
instances of the struct instead (cutting the arg list in half. Or...

C has no classes.

Even with C99's compound literals, the call is going to be
considerably more verbose than with alternating name-value arguments.
For example, in C99

func(WIDTH, 40, HEIGHT, 50, LAST_ARG);

might become

func((arg_type) {WIDTH, 40},
(arg_type){HEIG HT, 50},
(arg_type){LAST _ARG, 0});

And that's ignoring the possibility of different types of arguments,
which would probably require unions and named designators. It gets
very ugly very quickly.

C90 has no compound literals, so you'd need separate code to
initialize the argument objects before passing them to the function.
b) Cut it down to one arg by using something of the sort of a linked
list, thus just passing the first pointing, and the function keeps going
until it hits the NULL (end.)
Again, you's have to construct the linked list separatey before
calling the function, and destroy it afterwards.
c) not having used c for some time (been using c++ for year now after
using c for a while), I honestly can't remebmer if there are classes,
but iff you, one could write a Map or Hash type class, or just use
<map.h> :-)

See above.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

In article <42**********@s pool9-east.superfeed. net>,
Stan R. <st*********@br emove.lz.hmrpri nt.com> wrote:

a) Encapsolate the name-value pair to a struct or class, and pass
instances of the struct instead (cutting the arg list in half. Or...

b) Cut it down to one arg by using something of the sort of a linked
list, thus just passing the first pointing, and the function keeps going
until it hits the NULL (end.)

In one of the systems of this kind that I used, the original interface
was an array of name-value structs. This was verbose and tedious to
type, and the varargs version was added to make it more usable.

-- Richard

Kenny McCormack wrote:

int foo(int a) { return a; }

void bar(void) { return foo(1,2,3); }

Works fine on 99.99% of all hardware

Although you'd first have to write a compiler which accepts this.
Christian

In article <42************ ***********@new s.sunsite.dk>,
Christian Kandeler <ch************ ****@hob.de_inv alid> wrote:

Kenny McCormack wrote:

int foo(int a) { return a; }

void bar(void) { return foo(1,2,3); }

Works fine on 99.99% of all hardware

Although you'd first have to write a compiler which accepts this.

Christian

I'm sure compilers exist (from the early dawn era of prototypes)
that would, but today, you would just rearrange it to:

void bar(void) { return foo(1,2,3); }
int foo(int a) { return a; }

And ignore the warning about implicit declaration of foo().

Kenny McCormack wrote:

In article <42************ ***********@new s.sunsite.dk>,
Christian Kandeler <ch************ ****@hob.de_inv alid> wrote:

Kenny McCormack wrote:

int foo(int a) { return a; }

void bar(void) { return foo(1,2,3); }

Works fine on 99.99% of all hardware

Works fine? Meaning that you don't know what it does
and you don't know what it's supposed to do?

What is bar supposed to do?
A function call to bar has no value and no side effects.

It's just simply undefined.

N869
6.5.2.2 Function calls
Constraints
[#2] If the expression that denotes the called function has
a type that includes a prototype, the number of arguments
shall agree with the number of parameters.

6.8.6.4 The return statement
Constraints
[#1] A return statement with an expression shall not appear
in a function whose return type is void.
Although you'd first have to write a compiler which accepts this.

--
pete

In article <42***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

Kenny McCormack wrote:

In article <42************ ***********@new s.sunsite.dk>,
Christian Kandeler <ch************ ****@hob.de_inv alid> wrote:

>Kenny McCormack wrote:
>
>> int foo(int a) { return a; }
>>
>> void bar(void) { return foo(1,2,3); }
>>
>> Works fine on 99.99% of all hardware

Works fine? Meaning that you don't know what it does
and you don't know what it's supposed to do?

OK, little boy. Change it to "int bar" if it makes you happy.

Or change it from "return foo" to "printf foo" (with suitable syntax to
make it compilable).

Kenny McCormack wrote:

In article <42***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

Kenny McCormack wrote:

In article <42************ ***********@new s.sunsite.dk>,
Christian Kandeler <ch************ ****@hob.de_inv alid> wrote:
>Kenny McCormack wrote:
>
>> int foo(int a) { return a; }
>>
>> void bar(void) { return foo(1,2,3); }
>>
>> Works fine on 99.99% of all hardware

Works fine? Meaning that you don't know what it does
and you don't know what it's supposed to do?

OK, little boy. Change it to "int bar" if it makes you happy.

Or change it from "return foo" to "printf foo"
(with suitable syntax to make it compilable).

The point,
is that you're not paying attention to what you're saying,
because you know better than to do that.

--
pete

In article <42***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

Kenny McCormack wrote:

In article <42***********@ mindspring.com> ,
pete <pf*****@mindsp ring.com> wrote:

>Kenny McCormack wrote:
>>
>> In article <42************ ***********@new s.sunsite.dk>,
>> Christian Kandeler <ch************ ****@hob.de_inv alid> wrote:
>> >Kenny McCormack wrote:
>> >
>> >> int foo(int a) { return a; }
>> >>
>> >> void bar(void) { return foo(1,2,3); }
>> >>
>> >> Works fine on 99.99% of all hardware
>
>Works fine? Meaning that you don't know what it does
>and you don't know what it's supposed to do?

OK, little boy. Change it to "int bar" if it makes you happy.

Or change it from "return foo" to "printf foo"
(with suitable syntax to make it compilable).

The point,
is that you're not paying attention to what you're saying,
because you know better than to do that.

I see what you mean, but I think there is a sense in which you ought to be
able to read text posted here for content and in context - rather than just
looking for any little thing to nit-pick.

Obviously, the point of the thread and the thing being discussed was the
calling of foo() with more parameters than it was declared with. I think it
was clear enough to anyone what the point was, unless, of course, the
reader is, as is all too common in this ng, just reading to look for
something to nitpick. The declaration and use of bar was clearly outside
of the main channel of the discussion.