* [9fans] stdarg & va_copy @ 2008-01-24 18:10 erik quanstrom 2008-01-24 22:00 ` Russ Cox 2008-01-25 9:55 ` Douglas A. Gwyn 0 siblings, 2 replies; 8+ messages in thread From: erik quanstrom @ 2008-01-24 18:10 UTC (permalink / raw) To: 9fans is there any reason that /$objtype/include/u.h does not define va_copy? are there objections to this c99 macro? - erik ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-24 18:10 [9fans] stdarg & va_copy erik quanstrom @ 2008-01-24 22:00 ` Russ Cox 2008-01-24 22:07 ` erik quanstrom 2008-01-25 9:55 ` Douglas A. Gwyn 1 sibling, 1 reply; 8+ messages in thread From: Russ Cox @ 2008-01-24 22:00 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-24 22:00 ` Russ Cox @ 2008-01-24 22:07 ` erik quanstrom 2008-01-24 22:39 ` Russ Cox 0 siblings, 1 reply; 8+ messages in thread From: erik quanstrom @ 2008-01-24 22:07 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-24 22:07 ` erik quanstrom @ 2008-01-24 22:39 ` Russ Cox 2008-01-24 22:45 ` Pietro Gagliardi 0 siblings, 1 reply; 8+ messages in thread From: Russ Cox @ 2008-01-24 22:39 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-24 22:39 ` Russ Cox @ 2008-01-24 22:45 ` Pietro Gagliardi 2008-01-24 22:57 ` Charles Forsyth 0 siblings, 1 reply; 8+ messages in thread From: Pietro Gagliardi @ 2008-01-24 22:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-24 22:45 ` Pietro Gagliardi @ 2008-01-24 22:57 ` Charles Forsyth 0 siblings, 0 replies; 8+ messages in thread From: Charles Forsyth @ 2008-01-24 22:57 UTC (permalink / raw) To: 9fans > 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: = ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-24 18:10 [9fans] stdarg & va_copy erik quanstrom 2008-01-24 22:00 ` Russ Cox @ 2008-01-25 9:55 ` Douglas A. Gwyn 2008-01-25 14:18 ` erik quanstrom 1 sibling, 1 reply; 8+ messages in thread From: Douglas A. Gwyn @ 2008-01-25 9:55 UTC (permalink / raw) To: 9fans 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] stdarg & va_copy 2008-01-25 9:55 ` Douglas A. Gwyn @ 2008-01-25 14:18 ` erik quanstrom 0 siblings, 0 replies; 8+ messages in thread From: erik quanstrom @ 2008-01-25 14:18 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-01-25 14:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-01-24 18:10 [9fans] stdarg & va_copy erik quanstrom 2008-01-24 22:00 ` Russ Cox 2008-01-24 22:07 ` erik quanstrom 2008-01-24 22:39 ` Russ Cox 2008-01-24 22:45 ` Pietro Gagliardi 2008-01-24 22:57 ` Charles Forsyth 2008-01-25 9:55 ` Douglas A. Gwyn 2008-01-25 14:18 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).