🚀 go-pugleaf

In article <4g54pv$ajt@solutions.solon.com>, msb@sq.com says...
:
:I wrote:
:
:> > Thus even in ANSI C, if this function is called this way:
:> >
:> >     extern short p, q, r, test(short,short);
:> >     r = test(p,q);
:> >
:> > the values from p and q are still converted from short to int and back
:> > to short.  
:
:Thad Smith (ThadSmith@acm.org) responded:
:> I find nothing in the Standard that states that the arguments undergo
:> integral promotions before being assigned to the function parameters.
:
:This is in 6.2.1.1/3.2.1.1, the passage which defines the integral
:promotions.  It states that the promotions apply
:
:#  in an expression wherever an int or unsigned int may be used.
:
:Since the call test(1,2) is permissible, this means that p and q must
:be promoted to int.  As noted in my previous posting, they are then
:converted right back to short within the caller (since a prototype
:was used), and the compiler can easily optimize this out.
:

This is a somewhat perverse reading of the standard. It does not require 
pointless promotions followed by conversions back to the original type. In 
particular, there is a footnote to this section that says

	The integral promotions are applied only as part of the usual
	arithmetic conversions, to certain argument expressions, to the
	operands of the unary +, -, and ~ operators, and to both operands
	of the shift operators, AS SPECIFIED BY THEIR RESPECTIVE SECTIONS.
	[emphasis added]

That is, this section does not tell you what must be done every time you 
encounter something that could be promoted to int. It tells you what the term 
"integral promotions" means when it is used in other sections of the working 
paper. In particular, it tells you what "integral promotions" means in the 
context of the "usual arithmetic conversions", which is where it is most often 
encountered.

:Another example of this sort of thing is an assignment expression like
:p=q, where p and q are short.  q is promoted to int, then demoted back
:to short; since the value cannot change, the compiler optimizes out the
:conversions.  If you write p=(short)q, then the same reason applies
:to each of the expressions q and (short)q, and you end up with *two*
:round-trip conversions which should be optimized out.

No. The description of the semantics of the assignment operator does not 
mention integral promotions. Compare that with the description of the addition 
operator, which says, in part, "If both operands have arithmetic type, the 
usual arithmetic conversions are performed on them."