Issue 564: Description of constant expression semantics is unclear (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Resolution: resolved, closed issue Revised Text: replace 3rd para of 3.7.2 with the following (find full text in the corresponding archive file) Actions taken: May 1, 1997: received issue June 20, 1997: closed issue Discussion: End of Annotations:===== Issue 2: Description of constant expression semantics is unclear. Section 3.2.7 says: "No infix operator can combine an integer and a float. Infix operators are not applicable to types other than integer and float." "An integer constant expression is evaluated as unsigned long unless it contains a negated integer literal or the name of an integer constant with a negative value. In the latter case, the constant expression is evaluated as signed long. The computed value is coerced back to the target type in constant initializers. It is an error if the computed value exceeds the precision of the target type. It is an error if any intermediate value exceeds the range of the evaluated-as type (long or unsigned long)." First: "No infix operator can combine an integer and a float. Infix operators are not applicable to types other than integer and float." Infix operators are never defined or enumerated. I guess the author(s) meant { |, ^, &, +, -, *, \, % }, but this should be clarified. Next: "An integer constant expression is evaluated as unsigned long unless it contains a negated integer literal or the name of an integer constant with a negative value. In the latter case, the constant expression is evaluated as signed long." What if a sub-expression has a negative value? For example: const unsigned long i = 10 + (5 - 8); The sub-expression (5 - 8) is neither a negated integer literal (the minus sign is a binary subtraction operator, not a unary negation operator) nor the name of an integer constant with a negative value. Why should this be different from 10 + (-3) ? In fact, a strict reading implies that the original expression "10 + (5 - 8) is illegal, since the constant expression (5 - 8) is supposed to evaluate as an unsigned long, and -3 is not a legal unsigned value. "It is an error if the computed value exceeds the precision of the target type." I think this statement should read: "It is an error if the computed value exceeds the range of the target type." All integers have the same precision, that is, one. The various integer types vary in range, not precision. It is never explicitly stated whether or not an integer expression may assigned to a floating point target type (or vice versa) in a constant initializer. Can I do the following? float f = 2 / 3; int i = 5.0 + 2e1; If so, what is the value of f? My intuitive assumption is that the answer to the general question is no, but the text should be clearer. It would also help if the text would somehow clearly state that the third paragraph in section 3.7.2, beginning, "An integer constant expression is evaluated as unsigned long...", applied strictly to integer types, and that the next paragraph applies only to floating types. Regards, David Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Fri, 2 May 1997 08:13:39 +1000 (EST) From: Michi Henning To: David Curtis cc: issues@omg.org, orb_revision@omg.org Subject: Re: my issues Errors-To: owner-issues@omg.org Sender: owner-issues@omg.org X-OMG: orb_revision.5, issues.6 On Thu, 1 May 1997, David Curtis wrote: > "It is an error if the computed value exceeds the precision of the > target type." I'd like to follow up on that. Phrases like "It is an error..." are completely useless. What does it mean? That I made an error when I wrote the IDL? That because the IDL contains an error, it won't compile? That it will compile, but produce erroneous code? I would suggest a look at the ANSI-C standard, which very carefully defines the various error conditions, and what a conformant implementation must do for each condition. Options are: - undefined behavior at run-time - implementation-dependent behavior - implementation-defined behavior (the implementation must do something sensible and document what that is) - the compiler is obliged to issue a diagnostic - etc Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Fri, 2 May 1997 08:19:39 +1000 (EST) From: Michi Henning To: David Curtis cc: issues@omg.org, orb_revision@omg.org Subject: Re[2]: my issues Errors-To: owner-issues@omg.org Sender: owner-issues@omg.org X-OMG: orb_revision.6, issues.7 On Thu, 1 May 1997, David Curtis wrote: > It is never explicitly stated whether or not an integer expression may > assigned to a floating point target type (or vice versa) in a constant > initializer. Can I do the following? > > > float f = 2 / 3; There are a number of other cases that are undefined. For example: short s1 = 0xffff; unsigned short s2 = 0xffff; unsigned short s3 = ~0; In the absence of type promotion and coercion rules, the semantics of these definitions are anybody's guess. I'm not suggesting we need to go all the way and come up with mixed-mode arithmetic a'la C (presumably mixed-mode arithmetic was excluded to keep IDL compiler implementations simple). However, what is currently written in the spec is simply not rigorous enough. I suspect a subset of the ANSI-C typing rules could be adopted to make the spec a lot tighter. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html #564 CLOSED Section 3.7.2, page 3-18 Comment: The description of constant expression semantics is unclear. Resolution: Replace the third paragraph of 3.7.2 with the following: "An integer constant expression is evaluated as unsigned long, unless it contains a negative integer literal, or an integer constant with negative value, or other sub-expression with negative value, in which case it is evaluated as a signed long. The computed value is then coerced back to the target type in constant initializers. It is an error if the computed value exceeds the range of the target type, or if any intermediate value exceeds the range of the evaluated-as type (long or unsigned long)."