Defect Report #174
 
Submission Date: 16 Oct 95
Submittor: BSI
Source: Clive D.W. Feather
Question
Submitted to BSI by Clive D.W. Feather  clive@sco.com .
In this Defect Report, identifiers lexically identical to those 
declared in standard headers refer to the identifiers declared in  those
standard headers, whether or not the header is explicitly mentioned.
This Defect Report has been prepared with considerable help from 
Mark Brader, Jutta Degener, Ronald Guilmette, and a person whose
employment  conditions require anonymity. However, except where stated,
opinions  expressed or implied should not be assumed to be those of any
person  other than myself.
 Defect Report UK 022: Implicit conversions
 The wording dealing with the usual arithmetic conversions contains
 a number of errors; while the correct meaning is usually clear, a 
strict reading of the C Standard shows some contradictions and/or 
unwanted side-effects.
 Subclause 6.2.1.5 reads in part:
 Many binary operators that expect operands of arithmetic type 
cause conversions and yield result types in a similar way. The purpose 
is to yield a common type, which is also the type of the result.
 Subclause 6.3.15 reads in part:
 The second operand is evaluated only if the first compares unequal
 to 0; the third operand is evaluated only if the first compares equal 
to 0; the value of the second or third operand (whichever is evaluated) 
is the result.
 If both the second and third operands have arithmetic type,  the
usual arithmetic conversions are performed to bring them to a  common
type and the result has that type ... in which case the other  operand
is converted to type pointer to void, and the result has that  type.
 These citations have several defects:
 The relational and equality operators apply the usual arithmetic 
conversions, but not to yield the type of result.
 The conditional operator ?: is not a binary
operator,  but is specified as performing the usual arithmetic
conversions.
 The concept of conversions applies only to a value; subclause 
6.3.15 is therefore contradicting itself when it calls for both the 
second and third operands to be subject to conversion when only one  of
them is evaluated.
 The value of the result of the ?: operator is
not necessarily  that of the second or third operand, as the value may
have been converted  (possibly yielding a different value).
Suggested Technical Corrigendum
 In subclause 6.2.1.5, change the cited sentences to:
 Many operators cause the same pattern of conversions to be applied
 to two operands of arithmetic type. The purpose is to yield a common 
type, which, unless explicitly stated otherwise, is also the type  of
the operator's result.
 In 6.3.15, change the cited wording to:
 The second operand is evaluated only if the first compares unequal
 to 0; the third operand is evaluated only if the first compares equal 
to 0; the result of the operator is the value of the second or third 
operand (whichever is evaluated), converted to the type described 
below.
 If both the second and third operands have arithmetic type,  the
type that the usual arithmetic conversions would yield if applied  to
those two operands is the type of the result ... in which case  the type
of the result is pointer to void.
Previous Defect Report
< - > 
Next Defect Report