Function call with wrong number of parameters

Discussion in 'C Programming' started by arne, Mar 14, 2007.

  1. arne

    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?

    Thanks in advance,
    arne
     
    arne, Mar 14, 2007
    #1
    1. Advertising

  2. arne wrote:
    > 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.
     
    =?utf-8?B?SGFyYWxkIHZhbiBExLNr?=, Mar 14, 2007
    #2
    1. Advertising

  3. "arne" <> writes:
    > 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Mar 15, 2007
    #3
  4. On Mar 14, 5:05 pm, "arne" <> wrote:
    > 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
     
    William Hughes, Mar 15, 2007
    #4
  5. In article <>,
    William Hughes <> wrote:
    ....
    >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.
     
    Kenny McCormack, Mar 15, 2007
    #5
  6. On Mar 15, 7:14 am, (Kenny McCormack)
    wrote:
    > In article <>,William Hughes <> wrote:
    >
    > ...
    >
    > >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.



    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
     
    William Hughes, Mar 15, 2007
    #6
  7. arne

    Chris Dollin Guest

    William Hughes wrote:

    > On Mar 15, 7:14 am, (Kenny McCormack)
    > wrote:
    >> In article <>,William Hughes <> wrote:
    >>
    >> ...
    >>
    >> >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.

    >
    > 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++".

    --
    Chris "electric hedgehog" Dollin
    "Our future looks secure, but it's all out of our hands"
    - Magenta, /Man and Machine/
     
    Chris Dollin, Mar 15, 2007
    #7
  8. On Mar 15, 9:57 am, Chris Dollin <> wrote:
    > William Hughes wrote:
    > > On Mar 15, 7:14 am, (Kenny McCormack)
    > > wrote:
    > >> In article <>,William Hughes <> wrote:

    >
    > >> ...

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

    >
    > > 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++".
    >


    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
     
    William Hughes, Mar 15, 2007
    #8
  9. arne

    Chris Dollin Guest

    William Hughes wrote:

    > On Mar 15, 9:57 am, Chris Dollin <> wrote:
    >> William Hughes wrote:


    >> > 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++".

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

    --
    Chris "electric hedgehog" Dollin
    "I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/
     
    Chris Dollin, Mar 15, 2007
    #9
  10. "William Hughes" <> wrote in message
    news:...
    > 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

    --
    Stephen Sprunk "Those people who think they know everything
    CCIE #3723 are a great annoyance to those of us who do."
    K5SSS --Isaac Asimov


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Stephen Sprunk, Mar 15, 2007
    #10
  11. arne

    David Wade Guest

    "William Hughes" <> wrote in message
    news:...
    > On Mar 15, 9:57 am, Chris Dollin <> wrote:
    > > William Hughes wrote:
    > > > On Mar 15, 7:14 am, (Kenny McCormack)
    > > > wrote:
    > > >> In article

    <>,William Hughes
    <> wrote:
    > >
    > > >> ...

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

    > >
    > > > 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++".
    > >

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

    > - William Hughes
    >
     
    David Wade, Mar 15, 2007
    #11
  12. In article <> "William Hughes" <> writes:

    [ 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.
    --
    dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
    home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
     
    Dik T. Winter, Mar 16, 2007
    #12
  13. arne

    Chris Dollin Guest

    Dik T. Winter wrote:

    > In article <> "William Hughes" <> writes:
    >
    > [ 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.

    --
    Chris "Buffy hedgehog" Dollin
    "It took a very long time, much longer than the most generous estimates."
    - James White, /Sector General/
     
    Chris Dollin, Mar 16, 2007
    #13
  14. On Mar 15, 8:44 pm, "Dik T. Winter" <> wrote:
    > In article <> "William Hughes" <> writes:
    >
    > [ 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, Mar 16, 2007
    #14
  15. On Mar 15, 6:02 pm, "David Wade" <> wrote:
    > "William Hughes" <> wrote in message
    >
    > news:...> On Mar 15, 9:57 am, Chris Dollin <> wrote:
    > > > William Hughes wrote:
    > > > > On Mar 15, 7:14 am, (Kenny McCormack)
    > > > > wrote:
    > > > >> In article

    >
    > <>,William Hughes
    >
    >
    >
    > <> wrote:
    >
    > > > >> ...

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

    >
    > > > > 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++".

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


    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
     
    William Hughes, Mar 16, 2007
    #15
  16. arne

    CBFalconer Guest

    William Hughes wrote:
    >

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

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Mar 16, 2007
    #16
  17. On Mar 15, 2:40 pm, "Stephen Sprunk" <> wrote:
    > "William Hughes" <> wrote in message
    >
    > news:...
    >
    > > 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.


    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
     
    William Hughes, Mar 16, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pial
    Replies:
    4
    Views:
    56,736
    Phatman
    Aug 27, 2010
  2. Felix Kater

    Variable number of parameters in a function call?

    Felix Kater, Oct 9, 2004, in forum: C Programming
    Replies:
    10
    Views:
    506
    John Bode
    Oct 11, 2004
  3. Jason
    Replies:
    2
    Views:
    513
    Jonathan Mcdougall
    May 13, 2006
  4. grbgooglefan
    Replies:
    2
    Views:
    432
    Pascal Bourguignon
    Jan 30, 2008
  5. John Allen
    Replies:
    2
    Views:
    213
    John Allen
    Mar 3, 2009
Loading...

Share This Page