diamond@tkou02.enet.dec.com (diamond@tkovoa) (08/14/90)
In article <5930@darkstar.ucsc.edu> daniel@terra.ucsc.edu () writes: >Should a translator identify 1-1 as ``a constant expression evaluating >to zero,'' (even absent optimization)? I have added comp.std.c to the distribution for this article, because the C standard is almost vague on this as well. If C++ maintains compatibility with C here, then my best guess is: A translator does not have to compute the constant expression at compile time, but it does have to remember that the expression is constant. When the value is cast (or automatically converted) to a pointer, the compiled code has to remember that it was a constant, check if the computation yields zero, and if so then convert it to a null pointer. In other words, it is not necessary to do optimization, but if it is not done, the result has to be "as if" optimization were done. :-) -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com This is me speaking. If you want to hear the company speak, you need DECtalk.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/14/90)
In article <1916@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <5930@darkstar.ucsc.edu> daniel@terra.ucsc.edu () writes: >>Should a translator identify 1-1 as ``a constant expression evaluating >>to zero,'' (even absent optimization)? >I have added comp.std.c to the distribution for this article, because >the C standard is almost vague on this as well. The C standard is not at all vague about this; see section 3.4. "1-1" is definitely an integral constant expression with value zero. It may be used any place that the integral constant "0" could be used, including in constructing a null pointer constant (see section 3.2.2.3).
ark@alice.UUCP (Andrew Koenig) (08/15/90)
In article <1916@tkou02.enet.dec.com>, diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: > In article <5930@darkstar.ucsc.edu> daniel@terra.ucsc.edu () writes: > > >Should a translator identify 1-1 as ``a constant expression evaluating > >to zero,'' (even absent optimization)? > > I have added comp.std.c to the distribution for this article, because > the C standard is almost vague on this as well. Gee, it doesn't look vague to me. It says: (section 3.2.2.3): An integral constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare equal to a pointer to any object or function. Next: is 1-1 a constant expression? We look at section 3.4 and find that a constant expression is a `conditional-expression' with some restrictions: Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except where there are contained within the operand of a sizeof operator. An integral constant expression shall have integral type and shall only have operands that are integer constants, enumeration constants, character constants, sizeof expression, and floating constants that are the immediate operands of casts. Cast operators in an integral constant expression shall only convert arithmetic types to integral types, except as part of an operand to the sizeof operator. That looks pretty plain to me. 1-1 is an integral constant expression, and may therefore be used as a null pointer constant. In order to allow int* p = 1-1; while still prohibiting int* p = 2-1; it is necessary for the translator to compute the value of such expressions during compilation. It is not necessary, however, for a C++ translator to compute the value of constant expressions of non-integral type. -- --Andrew Koenig ark@europa.att.com
diamond@tkou02.enet.dec.com (diamond@tkovoa) (08/15/90)
In article <13550@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >Followup-To: comp.std.c++ I changed this to comp.std.c. Does everyone's inews do this to them? >In article <1916@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >>In article <5930@darkstar.ucsc.edu> daniel@terra.ucsc.edu () writes: >>>Should a translator identify 1-1 as ``a constant expression evaluating >>>to zero,'' (even absent optimization)? >>I have added comp.std.c to the distribution for this article, because >>the C standard is almost vague on this as well. >The C standard is not at all vague about this; see section 3.4. Yes, section 3.4 says that a constant expression CAN be evaluated during translation. It is sufficiently clear that the translator is NOT REQUIRED to do so. I think Daniel was asking if it has to be treated "as if" it were evaluated during translation, and Mr. Gwyn and I agree (for a change) on the likely answer. In order to avoid vagueness, however, the standard could have said that such expressions do have to be detected as constants even though they do not have to be compiled as constants. At least there does not seem to be a contradiction or other deviation from intended rules, but it does require guesswork. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com This is me speaking. If you want to hear the company speak, you need DECtalk.
rfg@NCD.COM (Ron Guilmette) (08/15/90)
In article <1916@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <5930@darkstar.ucsc.edu> daniel@terra.ucsc.edu () writes: > >>Should a translator identify 1-1 as ``a constant expression evaluating >>to zero,'' (even absent optimization)? > >I have added comp.std.c to the distribution for this article, because >the C standard is almost vague on this as well. If C++ maintains >compatibility with C here, then my best guess is: > A translator does not have to compute the constant expression... Neither the C standard nor E&S are vague about this at all. Clearly, 1-1 is "a constant expression evaluating to zero". -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/15/90)
In article <1923@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >Yes, section 3.4 says that a constant expression CAN be evaluated during >translation. It is sufficiently clear that the translator is NOT REQUIRED >to do so. Wrong, at least when the translator needs to evaluate the expression in order to perform the translation. If the translator is able to "intuit" the correct code without evaluation of constant expressions, it of course is allowed to do so, since the standard specifies external characteristics of the programs that a conforming translator must accept, not internal details of how a translator is actually implemented. However, a conforming implementation must ACT exactly as though constant expressions ARE evaluated in many contexts. Since I don't believe in magic, I don't know how it could obtain the required results without in fact evaluating the expressions, in some meaningful sense of the term "evaluate".
diamond@tkou02.enet.dec.com (diamond@tkovoa) (08/16/90)
In article <13555@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <1923@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >>Yes, section 3.4 says that a constant expression CAN be evaluated during >>translation. It is sufficiently clear that the translator is NOT REQUIRED >>to do so. >Wrong, at least when the translator needs to evaluate the expression in >order to perform the translation. Besides clearly NOT REQUIRING translation-time evaluations, I have also seen clear REASONS for this non-requirement. If your target machine can handle 128-bit ints, your host machine is not required to provide a simulator. "Wrong" appears wrong. >However, a conforming >implementation must ACT exactly as though constant expressions ARE >evaluated in many contexts. Yes, on this we agree -- but it is still a guess. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com This is me speaking. If you want to hear the company speak, you need DECtalk.
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/16/90)
In article <1924@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >Yes, on this we agree -- but it is still a guess. It's not a guess, it's a requirement of the standard. If you don't believe me send in a request for a formal interpretation and we'll tell you officially.
henry@zoo.toronto.edu (Henry Spencer) (08/16/90)
In article <1924@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >Besides clearly NOT REQUIRING translation-time evaluations, I have also seen >clear REASONS for this non-requirement... Given that the compiler is required to do type checking (must produce a diagnostic for a violation of the rules), it's going to have to evaluate constant expressions as subscripts in array declarations. >If your target machine can handle >128-bit ints, your host machine is not required to provide a simulator. Provided it can get exactly the same effect, which is going to be tricky. The *preprocessor* is not required to emulate target arithmetic, but the rest of the compiler is nailed down pretty strictly. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
diamond@tkou02.enet.dec.com (diamond@tkovoa) (08/17/90)
In article <1990Aug16.152345.29177@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1924@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >>Besides clearly NOT REQUIRING translation-time evaluations, I have also seen >>clear REASONS for this non-requirement. If your target machine can handle >>128-bit ints, your host machine is not required to provide a simulator. >Given that the compiler is required to do type checking (must produce a >diagnostic for a violation of the rules), it's going to have to evaluate >constant expressions as subscripts in array declarations. Section 3.5.4.2 has a SEMANTICS rule about compatible array types. I cannot find a similar CONSTRAINTS rule. Therefore it seems that the compiler is permitted but not required to do this type checking, and is not required to produce a diagnostic for a violation. >Provided it can get exactly the same effect, which is going to be tricky. >The *preprocessor* is not required to emulate target arithmetic, but the >rest of the compiler is nailed down pretty strictly. The rest of the compiler is nailed down IF IT CHOOSES to compute constant expressions. It can always choose to leave a computation for execution time. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com This is me speaking. If you want to hear the company speak, you need DECtalk.
drh@cs.Princeton.EDU (Dave Hanson) (08/17/90)
>> char * a; >> a = 1-1; >the assignment of an integer to a pointer is legal >iff the integer is a null pointer constant, >which by sec. 3.2.2.3 must be an integral constant >expression with the value 0. >so the 1-1 in the expressions above must >be computed at compile time to determine legality. Yes, because 3.3.16.1 has it in a constraints section. So it appears that, where the standard says that the compiler CAN compute constants at translation time, the standard almost lies. The compiler MUST compute constants at translation time. This is unfortunate (because a cross-compiler will become difficult). (It's not quite a lie because the standard's words don't contradict each other, only the implications do. Why say "can" when it means "must"?) -- Norman Diamond diamond@tkou02.enet.dec.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/18/90)
In article <1958@rossignol.Princeton.EDU> drh@cs.Princeton.EDU (Dave Hanson) writes: >So it appears that, where the standard says that the compiler CAN >compute constants at translation time, the standard almost lies. >The compiler MUST compute constants at translation time. >This is unfortunate (because a cross-compiler will become difficult). >(It's not quite a lie because the standard's words don't contradict each >other, only the implications do. Why say "can" when it means "must"?) The problem is that you are applying an unjustified interpretation to the wording of the 3.4 Description section. That sentences simply explains what constant expressions are all about; it cannot reasonably be interpreted as granting any additional license to the implementation. It does promise PROGRAMMERS that it is safe to use constant expressions.