🚀 go-pugleaf

In article <43kiup$ev3@news1.wing.net>, pgf@american.com (Paul G. Fox)
writes: 
|> Tanmoy Bhattacharya (tanmoy@qcd.lanl.gov) wrote:
|> : In article <434pa4$c4c@news1.wing.net>, pgf@american.com (Paul G. Fox)
writes:  
|> : |> 
|> : |> the vendor's introduction of array semantics causes my "&ap" to break.
|> 
|> : I do not understand this. In what context does a fully paranthesized
|> : expression `(*&a)' differ from `a' if `a' is an addressable lvalue?
|> 
|> : I believe this set of parantheses in the definition of va_arg is
mandatory.  
|> 
|> well, i've produced a smallish self-contained example of code that breaks
|> when va_list is a "typedef char *va_list[1]".
|> 
|> the gcc error when compiling the "broken" case is:
|>  vaarg.c: In function `func2':
|>  vaarg.c:86: warning: passing arg 1 of `func3' from incompatible pointer
type 

<snipped program fragment which does the following
  calls vararg function func1.
  func1 passes its va_list variable to func2.
  func2 tries to pass the address of the incoming variable to func3.
  func3 declares its parameter as va_list*>

Aha! I though you were asking about passing the address of a va_list variable
(i.e. directly from func1 to func3 in your case). That must work. Your case
however is different.

Because of the rewrite rules, the object seemingly declared to be va_list in
func2 (i.e. in `void func2(va_list ap)') need not actually be a va_list
variable: it could, as in your case, be a rewritten type. Naturally, you
cannot pass its address to something which expects va_list *.

I think that the implementation is allowed to do this. I think the same is
allowed for fpos_t and FILE etc. 

For example, I think the following program fragment is not strictly
conforming: 

#include <stdio.h>
int g(fpos_t *y);
int f(fpos_t x) {
 return g(&x);
}

because x is not guaranteed to have the type fpos_t (if fpos_t is an array
type), and hence &x is not guaranteed to have the type fpos_t*.

This may be a defect in the standard: I do not think that the rewrite rules
were meant to apply on predefined types like this: but the standard does not
state that such types are not rewritten, and it does not state that such
types are not array types.

In your case, your problem should disappear if you pass &ap from func1 to
func2, and this app to func3 (i.e. do not take the address of a va_list
_parameter_, though you _can_ take the address of a va_list variable.)

Passing ap instead of &ap (as someone pointed out) is not a solution if one
wants to continue to use ap after return from the routine.

Cheers
Tanmoy
-- 
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87544-0285,USA H:#3,802,9 St,NM87545
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]