Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #16562

Re: variadic function

Show all headers | View raw

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> [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.)

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

>> If the language were changed in this way, no
>> implementations would have to change; the existing behavior would still
>> be conforming.
>
> Of course it would, because when there is undefined behavior
> any behavior whatsoever is conforming.  Implementations might
> not be affected, but the semantics of programs are greatly
> affected.

Yes.  (Only the behavior of programs that pass excess arguments would be
affected; in my hypothetical situation, such programs probably wouldn't
have been written in the first place.)

>> I do not advocate such a change; I was merely speculating on the
>> consequences if the language had been defined that way from the
>> beginning (or at least from 1989).  As I wrote before, passing excess
>> arguments to a variadic function is almost certainly a programming
>> error; making such a call's behavior undefined would not be a great
>> burden.
>
> Under the current rule, it is possible (to give one example) to
> write 'printf()' in a way that is portable across different
> implementations, doing all output with 'putchar()', and that works
> for calls like the one above.  Under the revised rule, it isn't.

How so?  An implementation that satisfies the current rule would also
satisfy the hypothetical rule.  In hypothetical-C, the call's behavior
is undefined; it might as well do exactly what it does under the current
rule.

> The phrasing of your last sentence suggests that the notion of
> "excess arguments" is well-defined,

An "excess argument" to a variadic function is one for which va_arg() is
not invoked before the function calls va_end().

To put it another way, in hypothetical-C, the behavior of calling
va_end() without having called va_arg() for all the actual arguments is
undefined.

>                                     and that when it is
> well-defined it's okay either to do the additional work necessary
> to collect them (when it can be determined how to do so) or
> accept that any such calls will result in undefined behavior
> (when it cannot be so determined).  I think that's nuts.  More
> specifically, I think the first part is wrong -- there are cases
> where the number of arguments that should be processed depends on
> other program state that is simply unknowable at the call site --

Ok, that might be an interesting point.

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?

Now that you mention it, I can imagine such cases (I didn't think of any
before).  For example:

    const char *format_string;
    if (verbose) {
        format_string = "%d (%s)\n";
    }
    else {
        format_string = "%d\n";
    }
    printf(format_string, num, str);

But *if* the hypothetical rule I discussed had been in the language from
the beginning, programmers just wouldn't write code like the above.  It
wouldn't be that hard to write two printf calls.

I believe this would have been a minor inconvenience, rarely
encountered.

> and the second part is misguided -- functions that complete their
> task successfully should neither have to do more work to collect
> "extra" arguments nor be obliged to transgress into a domain of
> undefined behavior just because "extra" arguments were supplied.
> I see no reason to accept any additional programming burden
> along these lines, especially since allowing such cases to be
> undefined behavior produces no evident benefit.

I can imagine an implementation where a variadic function that
fails to consume all its arguments might cause Bad Things To Happen.
For example, each invocation of va_arg() might pop the corresponding
argument off the stack; failing to do so might leave the stack in an
inconsistent state.  It could have much the same effect as passing
two arguments to a non-variadic function with one parameter (say,
by casting a function pointer to an inappropriate type), which has
undefined behavior in C as it's currently defined.

That's probably the scenario I had in mind when I suggested the
hypothetical rule several months ago.

Of course since C does define the behavior in such cases, no C
conforming implementation can behave this way.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

variadic function Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-05 22:32 +0000
  Re: variadic function Keith Thompson <kst-u@mib.org> - 2011-11-05 15:50 -0700
    Re: variadic function Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-07 17:41 +0000
  Re: variadic function James Kuyper <jameskuyper@verizon.net> - 2011-11-05 18:53 -0400
    Re: variadic function Keith Thompson <kst-u@mib.org> - 2011-11-05 16:35 -0700
      Re: variadic function Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 01:36 +0000
  Re: variadic function Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 01:31 +0000
  Re: variadic function Barry Schwarz <schwarzb@dqel.com> - 2011-11-06 09:45 -0800
    Re: variadic function Keith Thompson <kst-u@mib.org> - 2011-11-06 11:38 -0800
      Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 23:24 -0800
        Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-01-25 02:54 -0800
          Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 18:22 -0800
            Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-01-31 21:50 -0800
              Re: variadic function James Kuyper <jameskuyper@verizon.net> - 2012-02-01 07:55 -0500
              Re: variadic function Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-01 08:06 -0500
                Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-02-01 11:42 -0800
              Re: variadic function Willem <willem@toad.stack.nl> - 2012-02-01 16:15 +0000
                Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-02-01 11:41 -0800
              Re: variadic function Shao Miller <sha0.miller@gmail.com> - 2012-02-01 13:41 -0500
                Re: variadic function blp@cs.stanford.edu (Ben Pfaff) - 2012-02-01 10:45 -0800
              Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:30 -0800
                Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-03-08 13:57 -0800
                Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:10 -0800
                Re: variadic function jgk@panix.com (Joe keane) - 2012-03-11 07:56 +0000
                Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-11 13:01 -0700
                Re: variadic function jgk@panix.com (Joe keane) - 2012-03-12 19:04 +0000
                Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 15:05 -0700

csiph-web