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.

[Richard Heathfield]

mdh said:

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

<snip>

>Once you have understood the message, you should fix your code
appropriatel y, and recompile.

Hi Richard,
You convinced me **long ago** not to ignore warnings. I think what you
perhaps missed, not that I ignored the warning, but I am trying to
figure out **what** and **why** I am doing with some of the macros.
So, to take your car analogy, it would be like a newly emerged person
from the depths of the Amazon rain forest, who somehow got his license
in England (not sure how far we can stretch this) saying "Why is
there a sign about a blind corner and what's more, what is a blind
corner", and finding out the hard way there is a good reason for
it...and hopefully not becoming undefined in the process!.

In this case, it's more like:

Me: "Drive on the left."
You: "Okay, I'll try driving on the right and see what happens."
Me: "Your funeral, not mine."

I understand your desire to grasp the mechanism behind the va macros. On
most machines, it's pretty simple really - va_list simply keeps track of
the first unused argument. When you call va_arg, telling it the type of
the argument, it yields the argument value and, as a side effect, updates
va_list by the right number of bytes to point to the /next/ argument.

But you don't actually need to know that to write C programs, and in fact
it's better (from a portability perspective) if you *don't* know, or if
you can at least pretend you don't know - because it might work
differently on a different machine.

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

[Barry Schwarz]

On Sun, 7 Sep 2008 01:46:27 -0700 (PDT), mdh <md**@comcast.n etwrote:

>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

But you executed code that did not compile correctly. Then you asked
why it appeared to work anyway and why your debugger showed something
you didn't expect. In this situation, the only way to get a
reasonable answer to those questions (ignoring whether the questions
are worth asking) is in a group that discusses your system. We can
tell you the behavior is undefined but we cannot tell you why your
debugger showed something (anything?) or why the code seemed to do
what you expected.

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

You mean that at this stage you still don't understand that the
arguments you pass to a function must match the parameters the
function expects? Ignore the why. Treat it as a language
restriction, no different than defining variables before using them or
only coding executable statements inside a function.

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

There are way too many wrong things to worry about **why** each is
wrong. You cannot add two pointers, you cannot multiply a pointer by
an integer, you cannot convert a pointer to a different type without
taking alignment into consideration, you can pass NULL to free but not
to getc, you can initialize an automatic variable with the result of a
function call but not a static variable, and on and on.

--
Remove del for email

[mdh]

On Sep 7, 10:57*am, Richard Heathfield <[e-mail].i nvalidwrote:

mdh said:

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

<snip>

Once you have understood the message, you should fix your code
appropriately, and recompile.

Hi Richard,
You convinced me **long ago** not to ignore warnings..

In this case, it's more like:

Me: "Drive on the left."
You: "Okay, I'll try driving on the right and see what happens."
Me: "Your funeral, not mine."

>
But you don't actually need to know that to write C programs, and in fact
it's better (from a portability perspective) if you *don't* know, or if
you can at least pretend you don't know - because it might work
differently on a different machine.

Richard...thank s for being so patient. I took a good look at a lot of
the discussions over the years in the clc...as I had plenty of time
last night! One thing I realized was that "undefined behavior" has
come up ad nauseum and, understandably, the gusto to explain each time
that once ub occurs...all discussion ends. So I can see how some of my
questions must frustrate sometimes, esp falling into the trap of
trying to discern why something is not working by looking at a result
after ub has occurred. Having said that, it does lead me to ask you
this.
If one sees a diagnostic ( and I specifically mean a warning) , should
I, as you newbie ( not you as the expert) assume that anything after
this is ub ( as far as I can see, a message does not actually use the
term 'ub'), and as such, my questions ought to be directed, if any to
the cause of the diagnostic, as opposed to the result. I think this is
the error I made in this line of questioning, esp when asked to show
code.

[Richard]

Barry Schwarz <sc******@dqel. comwrites:

On Sun, 7 Sep 2008 01:46:27 -0700 (PDT), mdh <md**@comcast.n etwrote:

>>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...com e on! Of course I don't think this can be ignored with
impunity. I think I can explain your incredulousness . You are

But you executed code that did not compile correctly. Then you asked
why it appeared to work anyway and why your debugger showed something
you didn't expect. In this situation, the only way to get a
reasonable answer to those questions (ignoring whether the questions
are worth asking) is in a group that discusses your system. We can
tell you the behavior is undefined but we cannot tell you why your
debugger showed something (anything?) or why the code seemed to do
what you expected.

Nonsense. Someone will be able to. Possibly there are more people here
using his platform because they are interested in C than populate the
"for that platform group".

So less of the "we".

The reason was, in fact, explained to him in this very thread.

And such practical examples, when contrasted with the mythical systems
we keep hearing of here, make great strides in convincing people WHY
"standard C" is better. It's just a pity too many of you run off and
hide behind the "we" and "off topic" rather than compare and contrast
REAL systems in the Standard C arena. Now *that* would be helpful to
people. Real people. With real compilers and platforms. And real
deadlines. And real issues.

[mdh]

On Sep 7, 11:20*am, Barry Schwarz <schwa...@dqel. comwrote:

**understanding ** why it is correct. The code would

You mean that at this stage you still don't understand that the
arguments you pass to a function must match the parameters the
function expects?

Barry, I appreciate all the help you have given. As to the specific
question above, I have to defend myself. I **thought** that the
arguments and parameters **did** match, as I conveniently ignored the
warning...which should be read as not quite understanding the
importance and gravity of ignoring a diagnostic. Hopefully, I will not
make that mistake again. However, if I ever do, I am sure it will be
pointed out again, with even greater gusto !! :-) ( see my answer
that I have just given to Richard, before I saw yours).

[Richard]

mdh <md**@comcast.n etwrites:

On Sep 7, 11:20Â*am, Barry Schwarz <schwa...@dqel. comwrote:

>**understandin g** why it is correct. The code would

You mean that at this stage you still don't understand that the
arguments you pass to a function must match the parameters the
function expects?

Barry, I appreciate all the help you have given. As to the specific
question above, I have to defend myself. I **thought** that the
arguments and parameters **did** match, as I conveniently ignored the
warning...which should be read as not quite understanding the
importance and gravity of ignoring a diagnostic.

Do you ignore road signs too?

[Nick Keighley]

On Sep 7, 7:33*pm, mdh <m...@comcast.n etwrote:

On Sep 7, 10:57*am, Richard Heathfield <[e-mail].i nvalidwrote:

<snip>

Richard...thank s for being so patient. I took a good look at a lot of
the discussions over the years in the clc...as I had plenty of time
last night! One thing I realized was that "undefined behavior" has
come up ad nauseum and, understandably, the gusto to explain each time
that once ub occurs...all discussion ends. So I can see how some of my
questions must frustrate sometimes, esp falling into the trap of
trying to discern why something is not working by looking at a result
after ub has occurred. Having said that, it does lead me to ask you
this.
If one sees a diagnostic ( and I specifically mean a warning) , should
I, as you newbie ( not you as the expert) assume that anything after
this is ub ( as far as I can see, a message does not actually use the
term 'ub'),

sadly no :-(
implementations are permitted to output diagnostics
for anything they feel the whim to do so.

For instance "unused variable" is poor style but harmless
(unless you meant to use the variable!)

Some compilers complain if you don't use the return value
of a function. Again mostly harmless.

I'm afraid you just have to learn. Parameter mismatch
is one you can't usually ignore.

As a rule of thumb strive for a "clean compile", no errors
or warnings. Sadly this isn't always possible.

Try to understand what the compiler is trying to say and
then decide if you can live with it.

and as such, my questions ought to be directed, if any to
the cause of the diagnostic, as opposed to the result. I think this is
the error I made in this line of questioning, esp when asked to show
code

--
Nick Keighley

[jameskuyper]

mdh wrote:
....

If one sees a diagnostic ( and I specifically mean a warning) , should
I, as you newbie ( not you as the expert) assume that anything after
this is ub ( as far as I can see, a message does not actually use the
term 'ub'), and as such, my questions ought to be directed, if any to
the cause of the diagnostic, as opposed to the result. I think this is
the error I made in this line of questioning, esp when asked to show
code.

It's a good rule of thumb that you should set your compiler to it's
most sensitive warning level, and write your code so that it doesn't
generate any warnings. Like most rules of thumb, you need to be
careful about applying this; some compilers will warn about a great
many things that they don't need to warn about - you should either
turn off those warnings, or ignore them. More importantly, unless you
understand why a warning message was issued, you can't be sure of the
correct way to fix it; some ways of turning off warnings don't do
anything about the actual problem; some ways even make it worse.

Unfortunately, as a newbie you have no easy way to distinguish between
legitimate warnings and unnecessary ones, between the right way to fix
something and the wrong way to fix it.. The hard way, which i strongly
recommend, is that you should always figure out why the warning is
being produced, before you make any decision about how to fix the
problem it's warning you about.

[Richard Heathfield]

mdh said:

<snip>

If one sees a diagnostic ( and I specifically mean a warning) , should
I, as you newbie ( not you as the expert) assume that anything after
this is ub ( as far as I can see, a message does not actually use the
term 'ub'), and as such, my questions ought to be directed, if any to
the cause of the diagnostic, as opposed to the result.

Yes. If in doubt, assume that a diagnostic message indicates a problem with
your code that must be fixed before proceeding. To fix the code, you must
understand what the diagnostic message is telling you. As I suggested
earlier, this isn't always as obvious as we might like.

If in serious doubt, well, ask.

(Note that the *absence* of diagnostic messages is certainly not a
guarantee that all is well.)

--
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, 12:32*pm, jameskuy...@ver izon.net wrote:

mdh wrote:

...

If one sees a diagnostic ( and I specifically mean a warning) , should
I, as you newbie ( not you as the expert) assume.......

Unfortunately, as a newbie you have no easy way to distinguish between
legitimate warnings and unnecessary ones,...... The hard way, which i strongly
recommend, is that you should always figure out why the warning is
being produced, before you make any decision about how to fix the
problem it's warning you about.

Well, Nick and James...that is the **strong** take home message from
this discussion for me. I think it will at the very least, serve to
focus the inquiry if I do ask the clc. Thank you both.