variadic function

[Keith Thompson]

[...]
Do you suggest that there are *realistic* cases where a call to a
variadic function passes N arguments, and the function itself processes
fewer than N arguments, and where this does not indicate a logical error
in the program?

void logmessage(const char *format, ...) {
if (logstream != NULL) {
va_list ap;
va_start(ap, format);
vfprintf(logstream, format, ap);
va_end(ap);
} else {
fputs("Logical error! (?)\n", stderr);
}
}

That's a great example, thanks!

 

[Tim Rentsch]

[snip]

If the standard did have the requirement you mention: "Do not call
va_end after va_start unless va_arg has been called to process
every argument in the calling sequence", what great inconvenience
would it cause?

The problem is it requires us to know things that we may
not know, namely, the number and types of arguments remaining.
Even if a motivating example isn't immediately obvious, that's
a chilling prospect.

The quoted discussion was a while ago, but I think what I had in mind is
that calling va_end "too soon" would have undefined behavior. For
example (assuming printf uses the <stdarg.h> mechanism), this:

printf("%s\n", "arg1", "ignored");

has well defined behavior; with the hypothetical rule, its behavior
would be undefined.

That's an issue right there. We are taking a statement that
has defined behavior now and changing the language so it has
undefined behavior. Don't you see a problem with that?

I would certainly see a problem with that if that were what I suggested.
I'm not talking about changing the language; I'm speculating about what
problems, if any, would have resulted if the language had been defined
that way from the beginning.

When C was standardized in 1989, it *could have* been defined so that
excess arguments cause undefined behavior. If it had, I don't believe
it would have caused any great inconvenience. (Changing it now *would*
cause great inconvenience.)

I believe behavior with printf(), etc, predates the first
C standard by at least a decade. At that time (ie, the
late 1970's or earlier) there was no notion of undefined
behavior - implementations just did what they did. So
what you're suggesting doesn't really make sense, historically.

If you thought such a hypothetical is not worth discussion, I would
have no argument. But you obviously do think it's worth discussion.

I respond for two reasons: first to clarify what suggestion
(or suggestions) are being made, second to give comments
about the hypothetical as a way of saying something about
potential similar proposals made non-hypthetically. Not
sure how well I've succeeded with those, but oh well.

[snip]

There's been enough discussion in the intervening
followups so that I'll just leave it here.

 

[Keith Thompson]

I believe behavior with printf(), etc, predates the first
C standard by at least a decade. At that time (ie, the
late 1970's or earlier) there was no notion of undefined
behavior - implementations just did what they did. So
what you're suggesting doesn't really make sense, historically.

The first C standard introduced the rule that calling printf() without a
proper declaration in scope has undefined behavior. Prior to that, this
program:

extern printf();
main() { printf("Hello, world\n"); }

would have been well behaved (i.e., would print "Hello, world" under
most or all implementations).

The standard imposed a *lot* of restrictions that rendered the behavior
of some existing code undefined -- including, if I'm not mistaken, the
first "hello, world" program in K&R1 (I don't remember whether it had
"#include <stdio.h>" or not).

Adding a rule that calling printf() with excess arguments has undefined
behavior would have been consistent with that.

I'm not saying it would necessarily have been a good idea to impose such
a rule, but it wouldn't have been completely insane.

[...]

 

[Tim Rentsch]

The first C standard introduced the rule that calling printf() without a
proper declaration in scope has undefined behavior. Prior to that, this
program:

extern printf();
main() { printf("Hello, world\n"); }

would have been well behaved (i.e., would print "Hello, world" under
most or all implementations).

True, but not nearly as relevant since all such problems could
be fixed by adding one line at the beginning of each source
file, without having to do any code inspection.

The standard imposed a *lot* of restrictions that rendered the behavior
of some existing code undefined -- including, if I'm not mistaken, the
first "hello, world" program in K&R1 (I don't remember whether it had
"#include <stdio.h>" or not).

Before C was standardized all C programs had undefined behavior
in every statement. The Standard defines the behavior of some
of those statements. Indeed it is defining behavior that imposes
a restriction - leaving something as undefined behavior imposes
no restrictions at all.

Adding a rule that calling printf() with excess arguments has undefined
behavior would have been consistent with that.

I disagree. I'm surprised you don't see a difference.

I'm not saying it would necessarily have been a good idea to impose such
a rule, but it wouldn't have been completely insane.

Maybe not completely insane, but still insane.

 

[Joe keane]

Before C was standardized all C programs had undefined behavior in
every statement.

It's BSD 4.1 on a VAX.

I defined it.

If another platform gives different results then it's a compiler bug or
ill-formed code.

 

[Tim Rentsch]

It's BSD 4.1 on a VAX.

I defined it.

If another platform gives different results then it's a compiler bug or
ill-formed code.

Presumably you're just making a joke. There is however an
underlying point that's worth making.

In running an actual program there is no such thing as "undefined
behavior". Every program execution does _something_, and it's
always possible to say that what the program does serves to
define the behavior.

The point, though, is that the term 'undefined behavior' means
behavior that is not defined by the ISO C Standard. Before there
was an ISO C Standard, no program behavior was defined, so all
parts of all C programs were undefined behavior.

(Note: I know that 'undefined behavior' meant something different
during the time that ANSI had ratified a C standard but before
ISO did. That doesn't change the point.)

 

[Joe keane]

Before there was an ISO C Standard, no program behavior was defined, so
all parts of all C programs were undefined behavior.

That i disagree with.

ANSI mainly codified current behavior. Therefore there was some current
behavior.

K&R predates ANSI by a bit. C compilers and libraries had been around
for a decade. There would be some common knowledge of what is valid C.

For example, "a++ = 1;" was nonsense even then.

Programmers were aware that there's a function called 'strcpy', and what
it does, and if some guys reversed the arguments, that is -broken-.

etc etc

 

[Tim Rentsch]

That i disagree with.

ANSI mainly codified current behavior. Therefore there was some current
behavior.

K&R predates ANSI by a bit. C compilers and libraries had been around
for a decade. There would be some common knowledge of what is valid C.

For example, "a++ = 1;" was nonsense even then.

Programmers were aware that there's a function called 'strcpy', and what
it does, and if some guys reversed the arguments, that is -broken-.

I agree with your facts, but the point was about the labels, not
the facts. The term 'undefined behavior' has a very specific
meaning in the context of both the group and the discussion in
question. There was current behavior, and there was general
agreement as to what most of that behavior would be, but there
was no 'defined behavior' in the sense of not being 'undefined
behavior' -- before there was a Standard, all behavior was
'undefined' as far as there being an ISO standard definition.