Created on 2005-04-14.00:00:00 last changed 161 months ago
[Voted into WP at the October, 2006 meeting.]
Proposed resolution (October, 2005):
Change 188.8.131.52 [expr.call] paragraph 7 as indicated:
...After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed.
If the argument has a non-POD class type (clause 9), the behavior is undefined.
The current wording of 184.108.40.206 [expr.call] paragraph 7 states:
When there is no parameter for a given argument, the argument is passed in such a way that the receiving function can obtain the value of the argument by invoking va_arg (17.13 [support.runtime]). The lvalue-to-rvalue (7.3.2 [conv.lval]), array-to-pointer (7.3.3 [conv.array]), and function-to-pointer (7.3.4 [conv.func]) standard conversions are performed on the argument expression. After these conversions, if the argument does not have arithmetic, enumeration, pointer, pointer to member, or class type, the program is ill-formed. If the argument has a non-POD class type (clause Clause 11 [class]), the behavior is undefined.
Paper J16/04-0167=WG21 N1727 suggests that passing a non-POD object to ellipsis be ill-formed. In discussions at the Lillehammer meeting, however, the CWG felt that the newly-approved category of conditionally-supported behavior would be more appropriate.
|2008-10-05 00:00:00||admin||set||status: wp -> cd1|
|2007-05-06 00:00:00||admin||set||status: dr -> wp|
|2006-11-05 00:00:00||admin||set||messages: + msg1432|
|2006-11-05 00:00:00||admin||set||status: ready -> dr|
|2006-04-22 00:00:00||admin||set||status: review -> ready|
|2005-10-22 00:00:00||admin||set||messages: + msg1232|
|2005-10-22 00:00:00||admin||set||status: drafting -> review|