[9fans] stdarg & va_copy - Plan9

This is a discussion on [9fans] stdarg & va_copy - Plan9 ; is there any reason that /$objtype/include/u.h does not define va_copy? are there objections to this c99 macro? - erik...

+ Reply to Thread
Results 1 to 8 of 8

Thread: [9fans] stdarg & va_copy

  1. [9fans] stdarg & va_copy

    is there any reason that /$objtype/include/u.h does not
    define va_copy? are there objections to this c99 macro?

    - erik

  2. Re: [9fans] stdarg & va_copy

    > is there any reason that /$objtype/include/u.h does not
    > define va_copy? are there objections to this c99 macro?


    Yes. The definition and semantics of va_copy are
    sufficiently murky that it seemed best to omit it.

    If you are porting code that uses va_copy, you can just
    #define va_copy(x, y) (x) = (y)
    in your own compatibility headers.

    I'm still annoyed that the C99 committee outlawed taking
    the address of a va_list.

    Russ


  3. Re: [9fans] stdarg & va_copy

    On Thu Jan 24 17:04:00 EST 2008, rsc@swtch.com wrote:
    > > is there any reason that /$objtype/include/u.h does not
    > > define va_copy? are there objections to this c99 macro?

    >
    > Yes. The definition and semantics of va_copy are
    > sufficiently murky that it seemed best to omit it.


    i didn't see anything in the definition that would make va_copy
    wrong given the plan 9 definition of va_list. is there a particular
    case on plan 9 that would be a problem?

    > If you are porting code that uses va_copy, you can just
    > #define va_copy(x, y) (x) = (y)
    > in your own compatibility headers.
    >
    > I'm still annoyed that the C99 committee outlawed taking
    > the address of a va_list.


    understandable. the whole thing is quite annoying.

    but plan 9 does have va_start and va_end. wouldn't make sense
    to have va_copy as well?

    - erik

  4. Re: [9fans] stdarg & va_copy

    > i didn't see anything in the definition that would make va_copy
    > wrong given the plan 9 definition of va_list. is there a particular
    > case on plan 9 that would be a problem?


    it might make sense to *have* va_copy, but since plan 9
    programs don't use va_copy, there's no need to provide
    an implementation. and honestly, the fewer people who
    use va_copy, the better.

    > but plan 9 does have va_start and va_end. wouldn't make sense
    > to have va_copy as well?


    plan 9 makes no claims of being C99 compliant,
    although it happens to have a few of the same extensions.
    va_start, va_end, and va_arg are from an earlier standard.
    those (in particular va_arg) provide useful functionality.
    va_copy does not.

    like i said, if you need it, it's easy to put a #define
    in your own compatibility headers. if you don't
    need it, don't worry about it.

    russ


  5. Re: [9fans] stdarg & va_copy

    One possible use of va_copy is in an implementation of print[f]()
    that supports an option to get a specific argument. For example,

    print("%2#s %1#s", "second", "first");

    prints

    first second

    For example, one could maintain an array of the first n va_list
    items, save them as they are read, and then use the copies when
    necessary. The other option is
    va_end()
    va_start()
    while (newcount < count)
    va_arg()
    which could flood your code.

    On Jan 24, 2008, at 5:39 PM, Russ Cox wrote:

    >> i didn't see anything in the definition that would make va_copy
    >> wrong given the plan 9 definition of va_list. is there a particular
    >> case on plan 9 that would be a problem?

    >
    > it might make sense to *have* va_copy, but since plan 9
    > programs don't use va_copy, there's no need to provide
    > an implementation. and honestly, the fewer people who
    > use va_copy, the better.
    >
    >> but plan 9 does have va_start and va_end. wouldn't make sense
    >> to have va_copy as well?

    >
    > plan 9 makes no claims of being C99 compliant,
    > although it happens to have a few of the same extensions.
    > va_start, va_end, and va_arg are from an earlier standard.
    > those (in particular va_arg) provide useful functionality.
    > va_copy does not.
    >
    > like i said, if you need it, it's easy to put a #define
    > in your own compatibility headers. if you don't
    > need it, don't worry about it.
    >
    > russ
    >



  6. Re: [9fans] stdarg & va_copy

    > One possible use of va_copy is in an implementation of print[f]()
    > that supports an option to get a specific argument. For example,


    we'd just use the copy operation provided by the language: =


  7. Re: [9fans] stdarg & va_copy

    erik quanstrom wrote:
    > is there any reason that /$objtype/include/u.h does not
    > define va_copy? are there objections to this c99 macro?


    Probably it was left out due to not being in the C90 spec.
    There shouldn't be any problem with it, but is it needed?

  8. Re: [9fans] stdarg & va_copy

    > erik quanstrom wrote:
    > > is there any reason that /$objtype/include/u.h does not
    > > define va_copy? are there objections to this c99 macro?

    >
    > Probably it was left out due to not being in the C90 spec.
    > There shouldn't be any problem with it, but is it needed?


    no. neither is va_end or the compiler accepting, but ignoring,
    the "restrict" qualifier. but we already do these things.

    on the other hand, it does limit needless incompatiblity.

    - erik

+ Reply to Thread