Function call with wrong number of parameters

[arne]

Hi all,

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;
}

main.c:
int main( void )
{
foo( 21 );
return 0;
}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?

Thanks in advance,
arne

 

[Guest]

Hi all,

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;
}

main.c:
int main( void )
{
foo( 21 );
return 0;
}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?

The behaviour is undefined if you even declare a function
inappropriately, let alone actually call it with the wrong number of
arguments. If you're lucky, you'll get a crash.

 

[Keith Thompson]

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;
}

main.c:
int main( void )
{
foo( 21 );
return 0;
}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?

It's undefined behavior.

In a properly written program, a prototype for foo() will be visible
at the point of the call (probably in a "foo.h" header), and a call
with the wrong number of arguments will be a constraint violation
requiring a compile-time diagnostic.

 

[William Hughes]

Hi all,

imagine I call a function, but omit one of the parameters, like:

foo.c:
void foo( int a, int b ) {

/* do something with a and b */
return;

}

main.c:
int main( void )
{
foo( 21 );
return 0;

}

The value of b is then undefined inside foo, or does the standard say
something about the initialization of omitted function arguments?

The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).

C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would

-be useful
-be relatively easy
-have few if any backwards compatability
issues

On the other hand, the fact that these features did not make
it into C99 suggests that I am wrong.

- William Hughes

 

[Kenny McCormack]

The behaviour is undefined (and if a prototype is in scope a
diagnostic must be issued (many compilers will issue a diagnostic
if a prototype is not is scope)).

C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would

-be useful
-be relatively easy
-have few if any backwards compatability
issues

The fact is that C just isn't that sort of language. If you want VB (or
even C++), you know where to find it.

 

[William Hughes]

...




The fact is that C just isn't that sort of language. If you want VB (or
even C++), you know where to find it.

But why do you say "C just isn't that sort of language"?

Is there something about the theory of the C language
that precludes this sort of feature?

It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.

What am I missing?


- William Hughes

 

[Chris Dollin]

But why do you say "C just isn't that sort of language"?

Because, when you look at it, it isn't that sort of language:
convenience features aren't C's strength.

Is there something about the theory of the C language
that precludes this sort of feature?

"It's not useful enough".

It seems to me that adding a syntax to the
prototype allowing for named and/or default parameters
is easy enough. If the compiler can identify the function,
then parsing and completing (if necessary) the provided
arguments is straightforward. If the compiler cannot
identify the function (e.g. function pointer)
then it has no choice but to use the arguments
provided and default methods.

What am I missing?

There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.

A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.

That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".

 

[William Hughes]

Because, when you look at it, it isn't that sort of language:
convenience features aren't C's strength.


"It's not useful enough".



There are many -- many, many, many -- simple and straightforward
features that might be added to C without doing violence to the
core. The trouble is, there are many, many, many such features,
of different value to different users, hence of different value
to different implementors, and of different levels of advocacy
in standards bodies.

A feature isn't useful if you can't reasonably expect to find
it in all the implementations you expect to be targets. Adding
a new feature isn't a matter of noticing that it's easy to
add and bingo! We have it now: it's a matter of convincing
sufficiently many implementors that their users will want it
that it becomes sufficiently widespread that everyone has to
have it.

That's discounting two other forces: that different
straightforward features may interact in crookedside ways,
and that for several such features have as a response "if you
need that, use C++".

True, but the same things apply to
e.g. prototypes and complex number support.

If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

- William Hughes

 

[Chris Dollin]

True, but the same things apply to
e.g. prototypes and complex number support.

Indeed.

They were winners. There were doubtless losers.

If the argument is simply

We can't add all features, this is one we decided not
to add

OK.

It's more: these are the features that have been proposed
(and have implementations), which of these provides the
appropriate bang per buck /in this committee's opinion/.

However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I don't know if that feature was /proposed/ for C99. If it
wasn't, it had no chance. If it was, it would have to have
got broad agreement. Perhaps it didn't -- for whatever reason.

What I'm saying is, the decision about which features make it
in and which don't is made by people with passions and prejudices
and mandates and finite time. A lot like life, really.

 

[Stephen Sprunk]

C has neither named parameters, no default values for ommited
parameters. Why I don't know. It strikes me that adding
these features would

-be useful
-be relatively easy
-have few if any backwards compatability
issues

On the other hand, the fact that these features did not make
it into C99 suggests that I am wrong.

All of the new features in C99 that I care about are ones that various folks
had implemented as extensions to their C89/90 compilers. Presumably the
things you list above could also be added to C99 as extensions, and if they
became popular they could be added to the standard in C0X. Since nobody has
even bothered with implementing such extensions to date, it seems that
they're not as useful and/or as easy as you think, and therefore it makes
little sense to standardize them.

If you disagree, go grab the GCC source, submit patches, and try to get some
advocacy going over in comp.std.c. Here in comp.lang.c, we discuss what
_is_, not what _could be_.

S

 

[David Wade]

True, but the same things apply to
e.g. prototypes and complex number support.

If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I am not sure why its usefull. Provided you pass pointers then can't you
just pass "NULL" for any thing you want to omit. I am also not sure about
difficulty to add. Assuming you have separate compilation units then at
present code can work without function prototypes. This would require them
(I think) because I am pretty sure the caller would have to create dummy
paramters for the missing ones. If I had a vote I don't think its one I
would give it to...

 

[Dik T. Winter]

[ About default parameter values and named arguments.]

> If the argument is simply
>
> We can't add all features, this is one we decided not
> to add
>
> OK. However, the (usefullness)/(difficulty to add) ratio
> seems to me to be quite high, higher than features that were
> added. Is this just a disagreement on the usefullness of
> the feature, or have I missed some difficulty in
> adding this feature.

I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?
And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.

 

[Chris Dollin]

[ About default parameter values and named arguments.]

If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?

Oh, that's easy-peasy: "the effect is undefined"!

And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.

If we don't like it, we demonise it. Er ... not that I'd reccommend
that as a general rule.

 

[William Hughes]

[ About default parameter values and named arguments.]

If the argument is simply

We can't add all features, this is one we decided not
to add

OK. However, the (usefullness)/(difficulty to add) ratio
seems to me to be quite high, higher than features that were
added. Is this just a disagreement on the usefullness of
the feature, or have I missed some difficulty in
adding this feature.

I do not think that this feature did even come up. Moreover, something along
the same features has already been done with structure initialisation, so
some of the syntax, actually, is already there. On the other hand, doing the
same for functions, comes pretty close to overloading, and would make quite a
few standard functions superfluous. Note, however, that the defaults *must*
be indicated in the prototype in order to have the same efficiency as
currently, and this can become quite confusing, e.g. what happens if you
call a function without a prototype in sight with insufficient parameters?
And especially so when in one place the definition serves as a prototype and
in another place there is only a declaration that serves as a prototype.
--

If you call a function without a declaration or definition in scope,
or only a
delclaration without parameter informationan, with the wrong
number and/or type of parameters then you are in nasal demon
territory. If a
declaration does not match the definition you are in nasal demon
territory [1].
Nothing new here. Still, I am not advocating the addition of default/
named parameters,
merely wondering whether there absence is due to some factor I had
not considered.

- William Hughes

[1] You do, of course, include foo.h in foo.c to catch this.

 

[William Hughes]

William Hughes wrote:
On Mar 15, 7:14 am, (e-mail address removed) (Kenny McCormack)
wrote:
<[email protected]>,William Hughes









I am not sure why its usefull. Provided you pass pointers then can't you
just pass "NULL" for any thing you want to omit. I am also not sure about
difficulty to add. Assuming you have separate compilation units then at
present code can work without function prototypes.

However, only if all calls to functions without prototypes use
the correct number and type of parameters. Adding default parameters
changes little. You could still call a function with default
parameters,
even without a prototype, as long as you include all parameters
(including default parameters).

If you use a coding style under which it is an error to call
a function without a prototype in scope
(except for the rare cases, eg function pointers,
where it is unavoidable) you cannot avoid prototypes.

This would require them

Only to use the new feature. If no declaration or definition
containing
default information was in scope, then the compiler could not assume
that missing parameters exist. This does not lead to problems that
are
not already there.


- William Hughes

 

[CBFalconer]

.... snip ...

If you use a coding style under which it is an error to call a
function without a prototype in scope (except for the rare cases,
eg function pointers, where it is unavoidable) you cannot avoid
prototypes.

It is trivial to provide default parameters effects, where needed.
Two examples are:

getchar() via #define getchar() getc(stdin)
ggets(p) via #define ggets(p) fggets(p, stdin)

where getchar is part of the standard library, and ggets is defined
in my own ggets.h file.

 

[William Hughes]

All of the new features in C99 that I care about are ones that various folks
had implemented as extensions to their C89/90 compilers. Presumably the
things you list above could also be added to C99 as extensions, and if they
became popular they could be added to the standard in C0X. Since nobody has
even bothered with implementing such extensions to date, it seems that
they're not as useful and/or as easy as you think, and therefore it makes
little sense to standardize them.

Indeed, but this just shifts the problem a bit. (I am aware that C90
and C99
to a large extent standardized existing extensions. What I am not
aware
of is whether any complier offers default/named parameters as an
extension.
Apparently not.) The question now becomes "why have they not been
implemented?".
The answer "it seems that they're not as useful and/or as easy as you
think"
while accurate, is not very useful. A bit more detail would be
helpful.

If you disagree, go grab the GCC source, submit patches, and try to get some
advocacy going over in comp.std.c.

If I had advocated their inclusion in C this would be good advice.

Here in comp.lang.c, we discuss what
_is_, not what _could be_.

As far a topicallity goes, the question "Why is feature X not found in
C?"
seem to me a good fit for comp.lang.c, (the slightly different
question
"Should feature X be added to the next C standard?" is clearly best
suited to comp.std.c).

- William Hughes