C++PATCH: va_arg & aggr type

Jason Merrill jason@cygnus.com
Tue Oct 5 10:38:00 GMT 1999


>>>>> Nathan Sidwell <nathan@acm.org> writes:

 > I can't determine whether va_arg should return an lvalue. I don't
 > have a C standard available. The C9X draft just says it is a macro
 > which expands to an expr of the specified type. The C++ standard
 > [lib.support.runtime] says nothing more about va_arg, but restricts
 > what va_start can be given.

If the standard doesn't say it's an lvalue, I think we should assume it's
not.

 > Anyway, should
 >         const int &i = va_arg (args, int);
 > be valid? I think yes, we're binding a reference to a temporary.

Yes, just as

	   int j = 42;
	   const int &i = j+2;

is valid.

 > This hints that
 >         const int *i = &va_arg (args, int)
 > needs to be constructable at least internally -- otherwise we force an
 > unnecessary copy.

That doesn't follow.  That's like saying that

	   const int *i = &(j+2);

needs to be constructable.

 > As C++ has non-POD types, I added build_x_va_arg (call.c), to validate
 > the type given to va_arg. It completes the type, checks for
 > completeness and warns about a non-POD. Although the standard does not
 > specify whether va_arg can accept a non-POD or not, it does prohibit
 > passing a non-POD in ellipsis.

Not exactly; it says that it's undefined, which means an implementation is
free to DTRT if it thinks it knows what TRT is.  We have decided that TRT
is to complain, so it makes sense to complain on both sides.

 > It occurs to me that we should also be decaying array and function types
 > here, (to match the default conversion in `...'), but I'm not sure.

I would agree.

 > *************** lvalue_p_1 (ref, treat_class_rvalues_as_
 > *** 142,147 ****
 > --- 142,148 ----
 >   			 treat_class_rvalues_as_lvalues);
  
 >       case TARGET_EXPR:
 > +     case VA_ARG_EXPR:
 >         return treat_class_rvalues_as_lvalues ? clk_class : clk_none;

We can get VA_ARG_EXPRs for non-class types, can't we?

Jason


More information about the Gcc-patches mailing list