Interleaved variable argument processing

Discussion in 'C Programming' started by Richard Heathfield, Aug 10, 2003.

  1. I was recently asked whether it is legal to start processing a variable
    argument list a second time, /before/ you've finished with it the first
    time. (I have no idea why the questioner might want to do this, I'm afraid.
    Since he's normally fairly bright, I presume he had a good reason for
    asking.)

    The following code illustrates the point, I think (but don't use it as a
    va_arg tutorial!, as it kinda assumes there are at least six args after the
    named arg):

    #include <stdio.h>
    #include <stdarg.h>

    int foo(int i, ...)
    {
    va_list ap = {0};
    va_list aq = {0};
    int sum = i;

    va_start(ap, i);
    sum += va_arg(ap, int);
    sum += va_arg(ap, int);
    va_start(aq, i);
    sum += va_arg(ap, int);
    sum += va_arg(ap, int);
    sum += va_arg(aq, int);
    sum += va_arg(aq, int);
    sum += va_arg(ap, int);
    sum += va_arg(aq, int);
    sum += va_arg(ap, int);
    sum += va_arg(aq, int);
    va_end(ap);
    sum += va_arg(aq, int);
    sum += va_arg(aq, int);
    va_end(aq);
    return sum;
    }

    int main(void)
    {
    printf("%d\n", foo(6, 5, 4, 3, 2, 1, 0));
    return 0;
    }

    Having read through the relevant section of C99, I could find no
    standard-based reason why this interleaving should not work (and, indeed,
    it does work on the single compiler I tested the code with).

    Did I miss something, or am I right in thinking this is a legal,
    well-defined technique?

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Aug 10, 2003
    #1
    1. Advertising

  2. Richard Heathfield

    Jason Guest

    There is this to note:

    [draft 99]

    I7.15.1.4

    clause 3.

    "...va_start shall not be invoked again for the same ap [ va_list type ]
    without an intervening invocation of va_end for the same ap."

    Given common compiler implementations it's not surprising that it works
    though.
     
    Jason, Aug 10, 2003
    #2
    1. Advertising

  3. Jason wrote:

    > There is this to note:
    >
    > [draft 99]
    >
    > I7.15.1.4
    >
    > clause 3.
    >
    > "...va_start shall not be invoked again for the same ap [ va_list type ]
    > without an intervening invocation of va_end for the same ap."
    >
    > Given common compiler implementations it's not surprising that it works
    > though.


    It's a different ap.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Aug 11, 2003
    #3
  4. "Ivan Vecerina" <ivecATmyrealboxDOTcom> wrote:

    <snip>
    >
    > And that's the only suggestion I would have regarding your sample
    > code: instead of calling va_start twice, why not use va_copy ?


    Perhaps because he doesn't have a C99 compiler. :)

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Aug 11, 2003
    #4
  5. Richard Heathfield

    Dan Pop Guest

    In <bh6skm$k1b$> Richard Heathfield <> writes:

    >"Ivan Vecerina" <ivecATmyrealboxDOTcom> wrote:
    >
    ><snip>
    >>
    >> And that's the only suggestion I would have regarding your sample
    >> code: instead of calling va_start twice, why not use va_copy ?

    >
    >Perhaps because he doesn't have a C99 compiler. :)


    A brilliant illustration of my point: far too many people no longer have
    a clear idea about what is a C feature and what is a C99 feature.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Aug 11, 2003
    #5
  6. "Dan Pop" <> wrote in message
    news:bh85sg$qpj$...
    | In <bh6skm$k1b$>
    | Richard Heathfield <> writes:
    |
    | >"Ivan Vecerina" <ivecATmyrealboxDOTcom> wrote:
    | >
    | ><snip>
    | >>
    | >> And that's the only suggestion I would have regarding your sample
    | >> code: instead of calling va_start twice, why not use va_copy ?
    | >
    | >Perhaps because he doesn't have a C99 compiler. :)
    |
    | A brilliant illustration of my point: far too many people no longer have
    | a clear idea about what is a C feature and what is a C99 feature.

    NB: Richard mentioned the C99 standard in his original post,
    so this is why I based my reply on this.

    This said, I agree with your point.

    IMHO, C99 and C90 deserve separate NGs nearly as much as C90 and C++98 do
    ... Maybe, maybe not ;)


    Kind regards,
    Ivan
    --
    http://www.post1.com/~ivec
     
    Ivan Vecerina, Aug 11, 2003
    #6
  7. Richard Heathfield

    Dan Pop Guest

    In <3f37b168$> "Ivan Vecerina" <> writes:

    >"Dan Pop" <> wrote in message
    >news:bh85sg$qpj$...
    >| In <bh6skm$k1b$>
    >| Richard Heathfield <> writes:
    >|
    >| >"Ivan Vecerina" <ivecATmyrealboxDOTcom> wrote:
    >| >
    >| ><snip>
    >| >>
    >| >> And that's the only suggestion I would have regarding your sample
    >| >> code: instead of calling va_start twice, why not use va_copy ?
    >| >
    >| >Perhaps because he doesn't have a C99 compiler. :)
    >|
    >| A brilliant illustration of my point: far too many people no longer have
    >| a clear idea about what is a C feature and what is a C99 feature.
    >
    >NB: Richard mentioned the C99 standard in his original post,
    > so this is why I based my reply on this.


    Another (related) point of mine: people read the C99 standard and
    expect their C89 implementations to behave accordingly. Which is sheer
    foolishness.

    >This said, I agree with your point.
    >
    >IMHO, C99 and C90 deserve separate NGs nearly as much as C90 and C++98 do
    > ... Maybe, maybe not ;)


    C99 already has a group. It's called comp.std.c. As long as
    practically nobody writes C99 code (using the C99 extensions supported
    by one C89 implementation or another doesn't count), there is little need
    for a newsgroup dedicated to C99 programming.

    Once people start using C99 implementations on a significant basis, c.l.c
    will naturally "migrate" towards C99, the same way it happened with c.s.c
    once the focus of the standardisation effort has moved from C89 to C9x.

    The current foolishness in comp.lang.c is practically due to the fact that
    an electronic copy of C99 can be cheaply obtained (and its last public
    draft is still available for free), which was never the case for C89/C90
    (whose electronic copy was both expensive and of poor quality: it
    contained a raw scan of standard's pages).

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Aug 11, 2003
    #7
  8. Richard Heathfield

    Dan Pop Guest

    In <bh9t3r$pue$> Richard Heathfield <> writes:

    >Dan Pop wrote:
    >
    >> Another (related) point of mine: people read the C99 standard and
    >> expect their C89 implementations to behave accordingly. Which is sheer
    >> foolishness.

    >
    >No, it's relatively low-gradient foolishness. C99 has done very little to
    >change the parts of C that are already defined by C90. Some, sure, but not
    >much.


    It doesn't matter how much: the text you're actually reading might be one
    of those few places where C99 changes the C89 specification. Do you like
    gambling on programming issues?

    Furthermore, it is quite common for C89 implementations to provide C99
    features as extensions, but with different semantics. E.g. snprintf on
    Solaris or inline and VLAs on gcc.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Aug 12, 2003
    #8
  9. Dan Pop wrote:

    > In <bh9t3r$pue$> Richard Heathfield
    > <> writes:
    >
    >>Dan Pop wrote:
    >>
    >>> Another (related) point of mine: people read the C99 standard and
    >>> expect their C89 implementations to behave accordingly. Which is sheer
    >>> foolishness.

    >>
    >>No, it's relatively low-gradient foolishness. C99 has done very little to
    >>change the parts of C that are already defined by C90. Some, sure, but not
    >>much.

    >
    > It doesn't matter how much: the text you're actually reading might be one
    > of those few places where C99 changes the C89 specification. Do you like
    > gambling on programming issues?


    No. I'd far rather use the C89 standard when writing C89 code.
    Unfortunately, I don't have a copy of the C89 standard, although I do have
    a draft, of course. Given the choice between gambling on a draft, and
    gambling on an authoritative standard text that has been revised, I'll take
    the latter, and combine it with the excellent group knowledge of
    comp.lang.c in an attempt to arrive at a low-risk strategy. That, in fact,
    was precisely what I was trying to do here.

    > Furthermore, it is quite common for C89 implementations to provide C99
    > features as extensions, but with different semantics. E.g. snprintf on
    > Solaris or inline and VLAs on gcc.


    What about interleaved variable argument processing? Does the published C89
    standard have anything to say on the matter?

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Aug 12, 2003
    #9
  10. Richard Heathfield

    Dan Pop Guest

    In <bhbknt$693$> Richard Heathfield <> writes:

    >Dan Pop wrote:
    >
    >> In <bh9t3r$pue$> Richard Heathfield
    >> <> writes:
    >>
    >>>Dan Pop wrote:
    >>>
    >>>> Another (related) point of mine: people read the C99 standard and
    >>>> expect their C89 implementations to behave accordingly. Which is sheer
    >>>> foolishness.
    >>>
    >>>No, it's relatively low-gradient foolishness. C99 has done very little to
    >>>change the parts of C that are already defined by C90. Some, sure, but not
    >>>much.

    >>
    >> It doesn't matter how much: the text you're actually reading might be one
    >> of those few places where C99 changes the C89 specification. Do you like
    >> gambling on programming issues?

    >
    >No. I'd far rather use the C89 standard when writing C89 code.
    >Unfortunately, I don't have a copy of the C89 standard, although I do have
    >a draft, of course. Given the choice between gambling on a draft, and
    >gambling on an authoritative standard text that has been revised, I'll take
    >the latter, and combine it with the excellent group knowledge of
    >comp.lang.c in an attempt to arrive at a low-risk strategy. That, in fact,
    >was precisely what I was trying to do here.


    Bad choice. The C89 draft is much closer to C89 than C99.
    Unsurprisingly. And most of the differences between the draft and C89
    are obvious to the competent C programmer (CLK_TCK instead of
    CLOCKS_PER_SEC, the wrong argument type for %o and %x in printf formats).

    >> Furthermore, it is quite common for C89 implementations to provide C99
    >> features as extensions, but with different semantics. E.g. snprintf on
    >> Solaris or inline and VLAs on gcc.

    >
    >What about interleaved variable argument processing? Does the published C89
    >standard have anything to say on the matter?


    Any good reason to expect the text to be different from the draft?
    Having access to both, I can confirm that the <stdarg.h> specification
    is the same in both documents.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Aug 13, 2003
    #10
  11. Dan Pop wrote:

    <snip>

    >>What about interleaved variable argument processing? Does the published
    >>C89 standard have anything to say on the matter?


    <snip>

    > Having access to both, I can confirm that the <stdarg.h> specification
    > is the same in both documents.


    There! That wasn't so hard, was it? Thanks for the confirmation.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Aug 14, 2003
    #11
    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. Ben Kial
    Replies:
    1
    Views:
    676
    Eric Enright
    Nov 15, 2004
  2. S?ren Gammelmark
    Replies:
    1
    Views:
    1,929
    Eric Sosman
    Jan 7, 2005
  3. Barzo
    Replies:
    2
    Views:
    652
    Jonathan Lee
    Apr 2, 2010
  4. AikidoGuy
    Replies:
    11
    Views:
    571
    Seebs
    Nov 21, 2011
  5. Joel VanderWerf
    Replies:
    3
    Views:
    152
    Joel VanderWerf
    Feb 14, 2004
Loading...

Share This Page