P 155 k&r section 7.3

[mdh]

Hi All,
The section is titled Variable-length Argument lists.
May I ask a question about the use of "macros".
To quote K&R.

"The standard header <stdarg.hcontai ns a set of macro definitions
that define how to step through an argument list...... The type
va_list is used to declare a variable...in minprintf..ap
.......The macro va_start initializes ap to point to the first unnamed
argument."

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

thanks in advance.

[Keith Thompson]

mdh <md**@comcast.n etwrites:

The section is titled Variable-length Argument lists.
May I ask a question about the use of "macros".
To quote K&R.

"The standard header <stdarg.hcontai ns a set of macro definitions
that define how to step through an argument list...... The type
va_list is used to declare a variable...in minprintf..ap
......The macro va_start initializes ap to point to the first unnamed
argument."

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

The reason va_start, va_arg, va_end, and va_copy are defined as macros
is that they *can't* be defined as functions.

For example, va_arg takes two arguments, an expression of type va_list
(I'm actually not sure it can be an arbitrary expression) and a type
name. It yields a result of the named type. A C function cannot take
a type name as an argument, only an expression, and it must return a
result of some single type that's specified when the function is
declared.

Now va_arg can't *portably* be defined as a macro either -- but
there's always some way to define it non-portably. In some cases, it
might even be necessary for the compiler to provide some extension
just for the purpose, and have the va_arg macro use that extension;
for example, an implementation might have something like

#define va_arg(ap, type) __builtin_va_ar g__(ap, type)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

mdh wrote:

Hi All,
The section is titled Variable-length Argument lists.
May I ask a question about the use of "macros".
To quote K&R.

"The standard header <stdarg.hcontai ns a set of macro definitions
that define how to step through an argument list...... The type
va_list is used to declare a variable...in minprintf..ap
......The macro va_start initializes ap to point to the first unnamed
argument."

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

You can't do this:

va_arg(arg, int)

with a function.

--
pete

[mdh]

On Sep 5, 5:20*pm, Keith Thompson <[e-mail] rote:

mdh <m...@comcast.n etwrites:

The section is titled Variable-length Argument lists.
May I ask a question about the use of "macros".
To quote K&R.

"The standard header <stdarg.hcontai ns a set of macro definitions

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

The reason va_start, va_arg, va_end, and va_copy are defined as macros
is that they *can't* be defined as functions.

For example, va_arg takes two arguments, an expression of type va_list
(I'm actually not sure it can be an arbitrary expression) and a type
name. *It yields a result of the named type. *A C function cannot take
a type name as an argument, only an expression,

So, in the example that is given on p156,

void minprintf(char *fmt, ...){

va_list ap;

? This declares ap a pointer of type va_list? And the reason ap is a
pointer is simply because that is the way it is defined??
Then,

va_start(ap, fmt);

So, from what you say, if I understand this, the type here (fmt) is
"pointer to char" and the expression 'ap' is initialized or "returned"
as a pointer to char (to the first argument)?

And just to make sure, an example here of va_arg use.
ival is declared an int.

so the expression

ival=va_arg(ap, int) will return a value ( ival) that is of
whatever_type ....in this case int, but could be char *, char etc?
So, although each of these macros does something a little different,
the common thread seems to be that the type of the argument is
unknown, and these macros provide a mechanism to deal with it?

[Keith Thompson]

mdh <md**@comcast.n etwrites:

On Sep 5, 5:20*pm, Keith Thompson <[e-mail] rote:

>mdh <m...@comcast.n etwrites:

The section is titled Variable-length Argument lists.
May I ask a question about the use of "macros".
To quote K&R.

"The standard header <stdarg.hcontai ns a set of macro definitions

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

The reason va_start, va_arg, va_end, and va_copy are defined as macros
is that they *can't* be defined as functions.

For example, va_arg takes two arguments, an expression of type va_list
(I'm actually not sure it can be an arbitrary expression) and a type
name. *It yields a result of the named type. *A C function cannot take
a type name as an argument, only an expression,

So, in the example that is given on p156,

void minprintf(char *fmt, ...){

va_list ap;

? This declares ap a pointer of type va_list? And the reason ap is a
pointer is simply because that is the way it is defined??

What makes you think va_list is a pointer type? The standard merely
says that it's "an object type suitable for holding information needed
by the macros va_start, va_arg, va_end, and va_copy". It could be a
pointer type, but it could just as easily be a structure or an array.

>
Then,

va_start(ap, fmt);

So, from what you say, if I understand this, the type here (fmt) is
"pointer to char" and the expression 'ap' is initialized or "returned"
as a pointer to char (to the first argument)?

va_start doesn't return anything. It initializes ap, an object of
type va_list. (That's part of the reason it's a macro; a function
can't modify an argument.) The va_list object exists to allow access
to the variadic arguments; you can think of it as a kind of abstract
index into the argument list.

The second argument to va_start is the name of the parameter just
before the ", ...".

The way in which this provides access to the following parameters is
entirely implementation-specific. If arguments are passed on a stack,
for example, a va_list object might be a pointer that gets advanced
through the region of memory containing the parameter objects. Or it
might be pure compiler magic.

And just to make sure, an example here of va_arg use.
ival is declared an int.

so the expression

ival=va_arg(ap, int) will return a value ( ival) that is of
whatever_type ....in this case int, but could be char *, char etc?

Right. Before calling va_arg, you have to already *know* what the
type of the next argument is going to be, and you have to know when to
stop. For something like printf, this is specified by the format
string. Or all the variadic arguments might be of the same pointer
type, with a null pointer marking the end of the list. Other schemes
are possible.

If you get the type wrong, for example if you call va_arg(ap, int)
when the next argument is actually of type char*, then you've just
entered the realm of undefined behavior.

So, although each of these macros does something a little different,
the common thread seems to be that the type of the argument is
unknown, and these macros provide a mechanism to deal with it?

Right.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[mdh]

On Sep 5, 7:21*pm, Keith Thompson <[e-mail] rote:

mdh <m...@comcast.n etwrites:

va_list ap;

? This declares ap a pointer of type va_list?

What makes you think va_list is a pointer type?

I was **deceived**!!! !

In K&R, va_list ap;

is followed by a comment

/*points to each unnamed arg in turn*/

so I assumed ap must be a pointer. :-)
*The standard merely

says that it's "an object type suitable for holding information needed
by the macros va_start, va_arg, va_end, and va_copy". *It could be a
pointer type, but it could just as easily be a structure or an array.

Then,

va_start(ap, fmt);

So, from what you say, if I understand this, the type here (fmt) is
"pointer to char" and the expression 'ap' is initialized or "returned"
as a pointer to char (to the first argument)?

va_start doesn't return anything. *It initializes ap, an object of
type va_list. *(That's part of the reason it's a macro; a function
can't modify an argument.)

The second argument to va_start is the name of the parameter just
before the ", ...".

The way in which this provides access to the following parameters is
entirely implementation-specific. *If arguments are passed on a stack,
for example, a va_list object might be a pointer that gets advanced
through the region of memory containing the parameter objects. *Or it
might be pure compiler magic.

thank you Keith.

[mdh]

On Sep 5, 5:20 pm, Keith Thompson <[e-mail] rote:

mdh <m...@comcast.n etwrites:

The section is titled Variable-length Argument lists.

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

The reason va_start, va_arg, va_end, and va_copy are defined as macros
is that they *can't* be defined as functions.

May I pursue another issue a little further.

K&R (p 155) declare minprintf thus:

void minprintf(char *fmt, ...);
When I followed the example, it did not seem to matter to the output
whether the declaration was

void minprintf(char *fmt, ...);
or

void minprintf(int fmt, ...);
The only difference is ( maybe the **only** will raise some chuckles)
that char *fmt points to all the arguments in my debugger, but int
returns an integer( surprise, surprise!). For fear of flogging a dead
horse, is that the difference?

[Kenny McCormack]

In article <3d************ *************** *******@b38g200 0prf.googlegrou ps.com>,
mdh <md**@comcast.n etwrote:

>On Sep 5, 5:20 pm, Keith Thompson <[e-mail] rote:

>mdh <m...@comcast.n etwrites:

The section is titled Variable-length Argument lists.

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

The reason va_start, va_arg, va_end, and va_copy are defined as macros
is that they *can't* be defined as functions.

May I pursue another issue a little further.

K&R (p 155) declare minprintf thus:

void minprintf(char *fmt, ...);
When I followed the example, it did not seem to matter to the output
whether the declaration was

void minprintf(char *fmt, ...);
or

void minprintf(int fmt, ...);

On many machines 'int' and 'char *' are the same size, have the same bit
representation, and are, basically, interchangeable . You can't rely on
this being true on all machines, of course...

[Barry Schwarz]

On Sat, 6 Sep 2008 11:46:27 -0700 (PDT), mdh <md**@comcast.n etwrote:

>On Sep 5, 5:20 pm, Keith Thompson <[e-mail] rote:

>mdh <m...@comcast.n etwrites:

The section is titled Variable-length Argument lists.

Could anyone help me understand the significance of using macros vs
functions, as I think it is more significant than I realize.

The reason va_start, va_arg, va_end, and va_copy are defined as macros
is that they *can't* be defined as functions.

May I pursue another issue a little further.

K&R (p 155) declare minprintf thus:

void minprintf(char *fmt, ...);
When I followed the example, it did not seem to matter to the output
whether the declaration was

void minprintf(char *fmt, ...);
or

void minprintf(int fmt, ...);

How were you able to check the first argument for '%' followed by 'd',
'f', or 's' if its type was int instead of char*?

>

The only difference is ( maybe the **only** will raise some chuckles)
that char *fmt points to all the arguments in my debugger, but int

What does this mean? How can a pointer in your code point to
something in your debugger? For that matter, how do you even pass
arguments to a debugger?

>returns an integer( surprise, surprise!). For fear of flogging a dead

Arguments don't "return" anything. Did you mean your debugger
displayed an integer?

>horse, is that the difference?

What difference? Show your code for a minprintf with an int as its
first parameter and a sample calling statement.

As coded in K&R, minprintf will handle variadic arguments (the ones
implied by the ...) of type int, double, and char* based on the
conversion specification in the format string.

If you change the parameter and argument to an int, how will minprintf
know the type of the next argument to extract? How will it know how
many arguments to extract?

--
Remove del for email

[mdh]

On Sep 6, 12:03*pm, gaze...@shell.x mission.com (Kenny McCormack)
wrote:

In article <3d002485-0189-49ff-bc1f-b5199f205...@b3 8g2000prf.googl egroups..com>,
On many machines 'int' and 'char *' are the same size, have the same bit
representation, and are, basically, interchangeable . *You can't rely on
this being true on all machines, of course...

thanks Kenny..there is clearly something I am not seeing...but
hopefully this will become clearer.