Getting at optional arguments

[Rob Hoelz]

So these two functions are different:

void foo(void);

and

void foo();

because the first one allows no arguments, but the second does. My
question is: In the implementation of the second function, how does
one get at those "optional" arguments?

Thanks!

[Ben Pfaff]

Rob Hoelz <ho***@wisc.eduwrites:

So these two functions are different:

void foo(void);

and

void foo();

because the first one allows no arguments, but the second does.

This is a misconception. The first declaration declares that
foo() has no parameters. The second declaration does not declare
foo()'s parameters and therefore says nothing about the type or
number of arguments that must be supplied. You can usually
invoke the function whether a prototype is specified or not[*],
but it is safer if you specify a prototype.
[*] Functions with a variable number of arguments are one exception,
functions that have parameters of type that is changed by the
default promotions is another, and I'm not sure that this is an
exhaustive list.

My question is: In the implementation of the second function,
how does one get at those "optional" arguments?

The arguments are not optional. They must be supplied, in the
same way that arguments must be supplied to any other function.

When the function is implemented, the parameters must be
specified, either in prototype form or the now-obsolete K&R form.
--
"For those who want to translate C to Pascal, it may be that a lobotomy
serves your needs better." --M. Ambuhl

"Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt

[Simon Biber]

Rob Hoelz wrote:

So these two functions are different:

void foo(void);

and

void foo();

because the first one allows no arguments, but the second does. My
question is: In the implementation of the second function, how does
one get at those "optional" arguments?

Neither of these functions have optional arguments.

A function with optional arguments must be declared with a prototype,
with at least one fixed argument followed by three dots ('...')
representing the optional arguments.

eg.
void foo(int a, ...);
or
void foo(int a, int b, ...);

You then get at these optional arguments using the va_* macros.

#include <stdarg.h>
#include <stdio.h>

/* Assume a is the number of optional args supplied, and
that each optional arg is an int. Print each argument. */

void foo(int a, ...)
{
int i;
va_list v;

va_start(v, a);

for(i = 0; i < a; i++)
{
printf("%d\n", va_arg(v, int));
}

va_end(v);
}

You can then use the function like this:

foo(0); /* doesn't print */
foo(1, 42); /* prints 42\n */
foo(2, 42, 69); /* prints 42\n69\n */

--
Simon.

[Default User]

Rob Hoelz wrote:

So these two functions are different:

void foo(void);

and

void foo();

because the first one allows no arguments, but the second does. My
question is: In the implementation of the second function, how does
one get at those "optional" arguments?

I assume you mean something along these lines:

#include <stdlib.h>
#include <stdio.h>

void f();

int main(void)
{
f(1,2);
return 0;
}

void f(int i)
{
/* how can we get at both 1 and 2? */
}
The answer is, you can't reliably, portably, or legally. The Standard
(well, n869) says the following:

J.2 Undefined behavior

[#1] The behavior is undefined in the following
circumstances:

[big snip]

-- For a function call without a function prototype, the
number of arguments does not agree with the number of
parameters (6.5.2.2).
So there's no legal way to even call the function with "optional"
parameters, let alone access them.

Depending on your implementation, there might be a way (as long as
demons are flying out of your nose anyway) to get at that extra
argument, assuming that your program didn't crash or use your credit
card to buy nude koala bear photos from the web. But any method you did
find would likely be non-portable.

The upshot is that it just isn't useful. If you need variable
parameters, there are ways to do it. That isn't it.


Brian

[Christopher Benson-Manica]

Default User <de***********@yahoo.comwrote:

The answer is, you can't reliably, portably, or legally. The Standard
(well, n869) says the following:

J.2 Undefined behavior

[#1] The behavior is undefined in the following
circumstances:

-- For a function call without a function prototype, the
number of arguments does not agree with the number of
parameters (6.5.2.2).

I found myself making a reference to 6.5.2.2 a few days ago in a
similar context, and I noticed that the Annex is "informative". Is
there also some normative text in 6.5.2.2 that explicitly states that
the behavior in this particular situation is undefined? Or is it
undefined by omission?

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Christopher Benson-Manica wrote:

Default User <de***********@yahoo.comwrote:

The answer is, you can't reliably, portably, or legally. The Standard
(well, n869) says the following:

J.2 Undefined behavior

[#1] The behavior is undefined in the following
circumstances:

-- For a function call without a function prototype, the
number of arguments does not agree with the number of
parameters (6.5.2.2).

I found myself making a reference to 6.5.2.2 a few days ago in a
similar context, and I noticed that the Annex is "informative". Is
there also some normative text in 6.5.2.2 that explicitly states that
the behavior in this particular situation is undefined? Or is it
undefined by omission?

"[...] If the number of arguments does not equal the number of
parameters, the behavior is unde�ned. [...]" (6.5.2.2p6)

[Default User]

Christopher Benson-Manica wrote:

Default User <de***********@yahoo.comwrote:

The answer is, you can't reliably, portably, or legally. The
Standard (well, n869) says the following:

J.2 Undefined behavior

[#1] The behavior is undefined in the following
circumstances:

-- For a function call without a function prototype, the
number of arguments does not agree with the number of
parameters (6.5.2.2).

I found myself making a reference to 6.5.2.2 a few days ago in a
similar context, and I noticed that the Annex is "informative". Is
there also some normative text in 6.5.2.2 that explicitly states that
the behavior in this particular situation is undefined? Or is it
undefined by omission?

Hmmm, good point. Perhaps that paragraph of the Standard is meant to
state explicitly what one can glean from elsewhere.


Brian