Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: variadic function |
| Date | 2011-11-06 11:38 -0800 |
| Organization | None to speak of |
| Message-ID | <lnaa89dory.fsf@nuthaus.mib.org> (permalink) |
| References | <j94dhl$6ua$1@speranza.aioe.org> <offdb75p2fm1j8vn65l6e0kvum4oik7v4t@4ax.com> |
Barry Schwarz <schwarzb@dqel.com> writes:
> On Sat, 5 Nov 2011 22:32:21 +0000 (UTC), Quentin Pope
> <qp19433@hotmail.NOSPAM.com> wrote:
>
>>Consider the variadic function with the following prototype:
>>int foo(int num,...);
>>Here 'num' specifies the number of arguments, and assume that all the
>>arguments that should be passed to this function are of type int.
>>(My question has nothing to do with the definition of the function
>>foo, so don't bother about it.)
>>
>>If I call the function as:
>>foo(2,3,4,5,6,7,8);/*More arguments than expected*/
>>
>>Here I call foo with too many arguments than expected by its
>>definition.
>
> Not by its definition which specifies only that the function call must
> have at least one argument. So your concern is actually about foo's
> execution.
>
> For sake of discussion, I will assume you meant that num contains the
> number of variable arguments, not the total number of arguments.
> Consider the similar situation where argument 1 is actually 6.
> Everything "matches". But during execution, after processing argument
> 3, foo decides there is some condition which warrants terminating its
> execution and returning to the caller. (Like free() determining that
> the input argument is NULL so there is no reason to do any more work.)
> However, foo is designed with sound programming practices in mind and
> as part of exiting cleans up after itself, including calling va_end
> (as required by 7.15.1.3-2). Since this situation occurs in lots of
> functions, C's utility as a programming language would be pretty
> limited if this by itself led to undefined behavior (and you would
> also see a requirement in the standard of the form "Do not call va_end
> after va_start unless va_arg has been called to process every argument
> in the calling sequence"). From the implementation's point of view
> (compiler, linker, run-time library, etc), this situation is the same
> as the one you described. The function will ignore some arguments. No
> one cares if it is because the value of num "hid" some of them or
> because the function decided they weren't needed. The result must be
> the same for C to be a practical language.
I don't quite follow this.
To be clear, I think we've established that there's no problem
with a variadic function processing only some of its arguments
(i.e., invoking va_end() without having used va_arg() to process
all the arguments).
But if the language were defined differently, I don't see that
it would be much of a problem. I can't think of many realistic
scenarios where it would even make sense to pass more arguments
to a variadic function than it's going to process. For example,
"foo(2,3,4,5,6,7,8);", though its behavior is well defined, is
probably a programming error.
The variadic functions I've seen either use a format string to
specify the number and types of the following arguments, or use
a special value, typically a null pointer, as an end marker.
In both cases, a correct call will result in all the arguments
being processed.
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?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"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
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