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:

On Sep 6, 4:08*pm, Barry Schwarz <schwa...@dqel. comwrote:

[...]

>Now, show us your code (the one with the first parameter declared as
an int) so we can explain what you are doing wrong, even if it is only
misinterpretin g what you see in the debugger.

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

int main (int argc, const char * argv[]) {
/*void minprintf(char *fmt, ...);*/
void minprintf(int fmt, ...);

minprintf("This is a test:\n%d:\n%s: \n%f:\n", 27, "More test",
-90.786);

/*warning: passing argument 1 of minprintf of incompatible pointer

This warning has nothing to do with the fact that minprintf is
variadic (i.e., has a ", ..." in its declaration). You declared a
function whose first parameter is of type int, and you called it with
a first argument of type char*.

type ( int fmt) */

return 0;
}

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

/* the role of char *fmt has been explained, but in 2 somewhat
different ways. Keith says "The *only* thing the "char *fmt, ..." part
of the declaration tells the compiler is that the first argument is of
type char*, and there
will be zero or more arguments of unspecified type(s) following that."
And Barry, you say that "The role of the char *fmt argument is to
allow the same function to handle different types and numbers of
arguments." Now my bet is that you are saying the same thing, but it
sounds somewhat different to me.

We're saying two quite different things, both of them true.

I told you what information "char *fmt, ..." conveys *to the
compiler*. If you call minprintf with a first argument of type char*,
and zero or more additional arguments of any type you like, the
compiler won't complain, because you haven't given it enough
information to do so.

Barry told you the *purpose*, in the sense of the program logic, of
the "char *fmt" parameter. Its purpose is to point to a string that
encodes the intended number and type(s) of the following arguments.
The compiler knows nothing about its purpose; it knows only what it
is.

A variadic function has no direct way to determine the number and
type(s) of any arguments corresponding to the "..." in the prototype
-- and yet it must execute just the right sequence of va_arg calls to
extract the values of those arguments. That means it has to have some
indirect way to determine that information. One common method is to
encode the information in a format string. Other methods are
possible.

[snip]

--
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"

[Richard Heathfield]

mdh said:

<snip>

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

/* the role of char *fmt has been explained, but in 2 somewhat
different ways. Keith says "The *only* thing the "char *fmt, ..." part
of the declaration tells the compiler is that the first argument is of
type char*, and there
will be zero or more arguments of unspecified type(s) following that."
And Barry, you say that "The role of the char *fmt argument is to
allow the same function to handle different types and numbers of
arguments." Now my bet is that you are saying the same thing, but it
sounds somewhat different to me.

They are saying different things, but both are correct. That is, one is
telling you about elephants in general, and the other is telling you about
this specific elephant.

What Keith is telling you (assuming you've quoted him correctly, which I
haven't checked - I'll trust you on that) is how the C compiler
understands the (char *fmt, ...) stuff. It sees char *, and thinks "Aha, a
pointer to char", sees fmt, and thinks "okay, I know its name now", sees
...., and thinks "whoa, variadic function, okay, no problem, I remember how
to do those"). It hasn't a clue what you're trying to do, what problem
you're trying to solve, so it has no idea whether char * is the type you
need or not.

What Barry is telling you is *why* bwk chose to use a char * for the first
argument - that is, he's explaining the purpose of fmt within the context
of this particular example function.

<snip>

va_start(ap, fmt);

/* So, here is the source of my confusion, and clearly the lack of
explaining it to the clc. I think this has been answered, so please
bear with me, but ap is now initialized to point to the first
unnamed argument. As Keith said "If the first argument were an int
rather than a char*, then minprintf wouldn't have any way of knowing
what argument values to grab." So I assume the initialization not only
points ap to the first argument, but it "types" the pointer as well,
and this information is conveyed by the expression "fmt".

No. You hand va_start the name of the last named parameter, the one that
occurs just before the ... bit, and it uses that information to get ready
to find (at RUNtime) the first unnamed argument value that has been passed
to this particular function. It doesn't actually find anything - not yet -
but it's ready when you are.

When you call va_arg(), you are telling the compiler that (a) you know
there's another argument to collect, and (b) you know its type. How do you
get that information, given that you can't see the calling function?
Answer: you establish a protocol, a contract, between the variadic
function and its caller. The protocol for minprintf is this: print all the
characters that you find in the fmt string, literally - UNLESS you
encounter a %s, a %d, or a %f. If you do encounter any of those, use
va_arg to obtain a char *, an int, or a double, respectively.

And,
rhetorically, I know the first argument is of type character, because,
""The *only* thing the "char *fmt, ..." part of the declaration tells
the compiler is that the first argument is of type char*" ( Keith).

No, the first parameter not only need not be of type character (by which I
presume you mean type char) but *is not* of that type. Keith is referring
to fmt itself, which is of type char *, not type char. The types of
subsequent parameters are unknown, so you have to work them out yourself.
The way minprintf does that is by using the fmt string. That isn't the
only way you could do it, but it's a very popular way.

For completeness,
debugger output (value of fmt) with declaration 'int fmt' =

Forget it. That isn't completeness. That's complete nonsense. Sorry, but
it's true - you can't just go round arbitrarily replacing syntax in the
wild hope that it might be meaningful.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Bacarisse]

mdh <md**@comcast.n etwrites:

On Sep 6, 4:08Â*pm, Barry Schwarz <schwa...@dqel. comwrote:

<snip>

>>Â*Why do you think
these functions are called variadic?

Wikipedia:"In computer programming, a variadic function is a function
of variable arity; that is, one which can take different numbers of
arguments."

I think they left out "and of different types".

I'd leave it out too. A function that took a variable number of
arguments that all had to be of the same type would still be variadic
and one that always took the same number would not be variadic even if
they could be of different types in different calls (that would be
polymorphic). In other words, the types of the arguments have nothing
to do with the function being (or not being) variadic.

Of course in C a variadic function can take arguments of any type as
well as of any number (provided then required arguments are given).

--
Ben.

[mdh]

On Sep 6, 6:40*pm, Keith Thompson <[e-mail] rote:

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

On Sep 6, 4:08*pm, Barry Schwarz <schwa...@dqel. comwrote:

[...]

Now, show us your code (the one with the first parameter declared as
an int) so we can explain what you are doing wrong, even if it is only
misinterpreting what you see in the debugger.

/*warning: passing argument 1 of minprintf of incompatible pointer

This warning has nothing to do with the fact that minprintf is
variadic (i.e., has a ", ..." in its declaration).

Was just trying to respond to the request of showing the code and
debugger information as fully as possible, without drawing any
inference from that.

>

type ( int fmt) */

*return 0;
}

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

/* the role of char *fmt has been explained, but in 2 somewhat
different ways. Keith says......
And Barry,......

We're saying two quite different things, both of them true.

I told you what information "char *fmt, ..." conveys *to the
compiler*. *If you call minprintf with a first argument of type char*,
and zero or more additional arguments of any type you like, the
compiler won't complain, because you haven't given it enough
information to do so.

Barry told you the *purpose*, in the sense of the program logic, of
the "char *fmt" parameter. *Its purpose is to point to a string that
encodes the intended number and type(s) of the following arguments.
The compiler knows nothing about its purpose; it knows only what it
is.

A variadic function has no direct way to determine the number and
type(s) of any arguments corresponding to the

>snip

>One common method is to
encode the information in a format string. *Other methods are
possible.

Thanks Keith for sticking with me. What I was trying to do was to
relate the "char *fmt", to the "..." and I finally, hopefully, get it,
thanks to your gentle persistence!!!! ! :-)

[mdh]

On Sep 6, 6:50*pm, Richard Heathfield <[e-mail].i nvalidwrote:

mdh said:

<snip>

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

/* the role of char *fmt has been explained, but in 2 somewhat
different ways. Keith says ....
And Barry, ....

They are saying different things, but both are correct....

>
What Keith is telling you .... is how the C compiler
understands the (char *fmt, ...) stuff. It sees char *, and thinks "Aha, a
pointer to char", sees fmt, and thinks "okay, I know its name now", sees
..., and thinks "whoa, variadic function, okay, no problem, I remember how
to do those"). It hasn't a clue what you're trying to do...

Well, in that respect, the compiler and I share something in
common!!!! :-) Seriously, you have very accurately articulated what I
have ignored up to now.

>
What Barry is telling you is *why* bwk chose to use a char * for the first
argument - that is, he's explaining the purpose of fmt within the context
of this particular example function.

Yep..got it.

>
So I assume the initialization not only

points ap to the first argument, but it "types" the pointer as well,
and this information is conveyed by the expression "fmt".

No. You hand va_start the name of the last named parameter, the one that
occurs just before the ... bit, and it uses that information to get ready
to find (at RUNtime) the first unnamed argument value that has been passed
to this particular function.

Ok...more clarity...thank you.

>
When you call va_arg(), you are telling the compiler that (a) you know
there's another argument to collect, and (b) you know its type.

snip

And,
rhetorically, I know the first argument is of type character, because,
""The *only* thing the "char *fmt, ..." part of the declaration tells
the compiler is that the first argument is of type char*" ( Keith).

. Keith is referring
to fmt itself, which is of type char *, ...... The types of
subsequent parameters are unknown, so you have to work them out yourself.

For completeness,
debugger output (value of *fmt) with declaration 'int fmt' =

Forget it. That isn't completeness. That's complete nonsense.

Richard, included trying to respond to the request "Now, show us your
code (the one with the first parameter declared as an int) so we can
explain what you are doing wrong, even if it is only misinterpreting
what you see in the debugger"

Richard and Keith...thanks so much for sticking with me. You have now,
hopefully, (until the next section at least) brought me one step
further away from being "undefined" ! :-)

[mdh]

On Sep 6, 7:05*pm, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

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

On Sep 6, 4:08*pm, Barry Schwarz <schwa...@dqel. comwrote:

<snip>

>*Why do you think
these functions are called variadic?

Wikipedia:"In computer programming, a variadic function is a function
of variable arity; that is, one which can take different numbers of
arguments."

I think they left out "and of different types".

I'd leave it out too. *A function that took a variable number of
arguments that all had to be of the same type would still be variadic
and one that always took the same number would not be variadic even if
they could be of different types in different calls (that would be
polymorphic). *In other words, the types of the arguments have nothing
to do with the function being (or not being) variadic.

Of course in C a variadic function can take arguments of any type as
well as of any number (provided then required arguments are given).

--
Ben.

Thanks Ben.

[pete]

mdh wrote:

What I was trying to do was to
relate the "char *fmt", to the "..."

That's what va_list and va_start and va_end do.

--
pete

[Barry Schwarz]

On Sat, 6 Sep 2008 18:16:07 -0700 (PDT), mdh <md**@comcast.n etwrote:

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

int main (int argc, const char * argv[]) {
/*void minprintf(char *fmt, ...);*/
void minprintf(int fmt, ...);

minprintf("This is a test:\n%d:\n%s: \n%f:\n", 27, "More test",
-90.786);

/*warning: passing argument 1 of minprintf of incompatible pointer
type ( int fmt) */

And for some reason you think this can be ignored with impunity?

>
return 0;
}

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

unrelated commentary snipped

va_list ap;

ditto

int ival;
double dval;
char *p, *sval;
va_start(ap, fmt);

/* So, here is the source of my confusion, and clearly the lack of
explaining it to the clc. I think this has been answered, so please
bear with me, but ap is now initialized to point to the first
unnamed argument. As Keith said "If the first argument were an int

No, it points to the argument named format which should be the last
named argument.

>rather than a char*, then minprintf wouldn't have any way of knowing
what argument values to grab." So I assume the initialization not only
points ap to the first argument, but it "types" the pointer as well,
and this information is conveyed by the expression "fmt". And,
rhetorically , I know the first argument is of type character, because,
""The *only* thing the "char *fmt, ..." part of the declaration tells
the compiler is that the first argument is of type char*" ( Keith).

For completeness,
debugger output (value of fmt) with declaration 'int fmt' =
1416128883 ( what I see in debugger as I step through the code)

Since you have already invoked undefined behavior, the debugger output
is irrelevant.

>debugger output (value of fmt) with declaration char *fmt = "This is
a test:\n%d:\n%s: \n%f:\n" ( as above)
debugger output (value of *ap) ( int fmt) = 0 '\0'
debugger output (value of *ap) ( char *fmt) = 0 '\0'

On my system, va_list is conditionally defined as either a typedef for
a struct or a typedef for a char*. If it is the same on yours, the
attempting to display *ap in the debugger may not be meaningful.

>
*/
for ( p=fmt; *p; p++){

Didn't your compiler generate the mandatory diagnostic here also? Why
did you ignore it?

>
/*So, the first argument, in my case "This is a test:\n%d:\n%s: \n%f:
\n" is now assigned to the char *p */

if ( *p != '%'){
putchar(*p);
continue;
}
switch (*++p) {
case 'd':
ival=va_arg(ap, int);

/* this part I get, I hope :-). Each call of va_arg returns 1 argument

Since va_arg is not a function, you are not calling anything. Look up
your varargs.h and see the actual code that will be executed.

>and steps ap to the next argument but in addition, types ap correctly
for the expected value, in the above case, and integer*/

printf("%d", ival);
break;
case 'f':
dval=va_arg(ap, double);
printf("%f", dval);
break;
case 's':
for ( sval = va_arg(ap, char*); *sval; sval++)
putchar(*sval);
break;
default:
putchar(*p);
break;
}
}
va_end(ap);
}

--
Remove del for email

[Richard Heathfield]

Two minor nits.

Barry Schwarz said:

On Sat, 6 Sep 2008 18:16:07 -0700 (PDT), mdh <md**@comcast.n etwrote:

<snip>

>>
/* So, here is the source of my confusion, and clearly the lack of
explaining it to the clc. I think this has been answered, so please
bear with me, but ap is now initialized to point to the first
unnamed argument. As Keith said "If the first argument were an int

No, it points to the argument named format which should be the last
named argument.

It's called fmt, not format.

<snip>

>>/* this part I get, I hope :-). Each call of va_arg returns 1 argument

Since va_arg is not a function, you are not calling anything. Look up
your varargs.h and see the actual code that will be executed.

stdarg.h, not varargs.h - and bear in mind that it needn't be a file to be
conforming, so it might not be viewable (and in any case it probably
wouldn't help him to get so involved in platform-specific stuff).

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[mdh]

On Sep 7, 1:04*am, Barry Schwarz <schwa...@dqel. comwrote:

On Sat, 6 Sep 2008 18:16:07 -0700 (PDT), mdh <m...@comcast.n etwrote:

/*warning: passing argument 1 of minprintf of incompatible pointer
type ( int fmt) */

And for some reason you think this can be ignored with impunity?

Barry...come on! Of course I don't think this can be ignored with
impunity. I think I can explain your incredulousness . You are
**rightly** concerned with writing correct code. But you **also**
understand **why** it is correct. Now imagine if I just corrected
something without **understanding ** why it is correct. The code would
be correct, but I would be back next week making the same
error...well, that's the way I work. I obviously asked in such a way
that it was not obvious what I was trying to understand...bu t
eventually, thanks to you and others who stuck with me...I understand
the concept. In **trying** to understand the concept, I often find it
helpful to understand **why** something is wrong. Does that make
sense?

Let me just say that despite what you may think, I pay really close
attention to what you, and the others have to say. My only error is
perhaps to be persistent until I **get** it. If this comes across as
ignoring the obvious, or not giving heed to what you say, that is not
my intention.