1

I am quite surprised that C does not guarantee that certain (constant) expressions are evaluated at compile (translation) time.

C11 (6.6 Constant expressions) (emphasis added):

A constant expression can be evaluated during translation rather than runtime, ...

Hence, two questions:

  1. Is there a standard way to guarantee that a certain (constant) expressions will be evaluated at compile (translation) time?
  2. Extra question: why C does not guarantee it? What were the (technical) obstacles to guarantee it?

UPD20230711. In _Static_assert declaration an integer constant expression is required to be evaluated at translation time, because per Semantics section (C11, 6.7.10p3) an implementation checks whether the constraint is violated. If the constraint is violated, then the implementation is required to produce a diagnostic message. If the diagnostic message is produced at translation time, then the integer constant expression is evaluated at translation time. This means that in some contexts a constant expression can (i.e. not required) be evaluated at compile (translation) time (e.g. switch(<const_expr>), in other contexts a constant expression shall (i.e. required) be evaluated at compile (translation) time (e.g. _Static_assert (<const_expr>, "");.

pmor
  • 5,392
  • 4
  • 17
  • 36
  • 4
    You can "guarantee" it by typing in the evaluated version. What's the problem you're trying to solve? Normally this is done in an optimized build. but if you've hit a circumstance where it doesn't, that would be worth explaining in more detail. – tadman Apr 26 '21 at 10:58
  • 1
    I think it's safe to assume that a C compiler will evaluate whatever constant expressions it can at compile time ([within reason](https://stackoverflow.com/q/3136686/1679849)). If it really matters, you could use a Makefile to compile and run a program that does all these evaluations and outputs a header file that you can then include in the rest of your C source code. – r3mainer Apr 26 '21 at 11:11
  • 3
    5.1.2.3/1 "The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant." – Ian Abbott Apr 26 '21 at 11:16
  • 3
    Not in theory. A C interpreter that reports all required diagnostic messages in an initial scan of a program and defers all other work until execution is, in regard to the observable behavior required by the C standard, indistinguishable from a traditional C implementation with separate compiling, linking, and execution. – Eric Postpischil Apr 26 '21 at 11:32
  • 3
    Enum members are calculated at compile time. E.g. `enum {A = 1, B = A + 7, C = A + B, D = C / B};`. Please don't ask me how far this can be stretched. – Wör Du Schnaffzig Apr 26 '21 at 11:54
  • 1
    Just for 'entertainment' value, here is Microsoft's take on [C Constant Expressions](https://learn.microsoft.com/en-us/cpp/c-language/c-constant-expressions?view=msvc-160). – Adrian Mole Apr 26 '21 at 14:42
  • 1
    Is there a specific case you're seeing where this is affecting you? If so, could you show that code? – dbush Apr 26 '21 at 14:49
  • @tadman _What's the problem you're trying to solve?_ The question is tagged `language-lawyer`. Actually, there are number if issues coming out the fact that "you'd never know at which time the expression will be evaluated". I.e. it is not possible (except non-standard behavior: #pragmas, options) to "control the evaluation time": compile time or run time. – pmor Jun 07 '21 at 21:28
  • @tadaman Example: it is known fact that compilers may contain (and contain) bugs in compile time FP implementation (used during constant folding). So, you'd prefer to avoid the risk of facing these bugs by forcing all FP computations be done at run time. But hey: in standard C you cannot do it. Period. – pmor Jun 07 '21 at 21:32

2 Answers2

1

This may be just mildly ambiguous use of English: The term, "can," is (IMHO) here used to express the logical possibility that the expression is compile-time evaluable, rather than an optional, implementation directive.

If we take the full text of the paragraph you cite from the Standard (bold italics for emphasis are mine), then there is, I believe, a guarantee that the evaluation effectively takes place at compile time:

6.6 Constant expressions
…

Description
2   A constant expression can be evaluated during translation rather than runtime, and accordingly may be used in any place that a constant may be.

Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
  • I don't think that it is _just mildly ambiguous use of English_. The standard is (usually) precise: _shall_ / _shall not_ is interpreted as a requirement / prohibition. For constant expressions we see that they _can_ be evaluated and _may_ be used. – pmor Nov 22 '21 at 20:39
1

The C standard in general is unhelpful in describing what may go on at compile-time and run-time respectively. The whole language is based on the (rather unhelpful) concept of an "abstract machine" in C17 5.1.2.3

The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant.
...
Evaluation of an expression in general includes both value computations and initiation of side effects...
In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced...

The above includes the formal definition of evaluation, which is also rather unhelpful. Basically the implementation is free to do anything in the ways of optimizations as long as side effects and "the observable behavior" are respected. There are no requirements placed stating that the compiler must perform certain optimizations. It's possible to build a compiler with no optimizations at all and it can still be a conforming implementation.

As for 6.6 and constant expression, the intention is surely to state the rules for what makes valid compile-time constants. In case integer constant expressions aren't evaluated at compile-time, then it becomes very impractical to generate an executable, to the point where the whole language would collapse. Indirectly, there are many requirements that can't be fulfilled unless constant expressions are evaluated at compile-time.

For example, if array sizes of static storage duration objects weren't known at compile-time, then how would you generate the start-up code for initializing them? It must occur before main() is called - this is actually guaranteed by 5.1.2:

All objects with static storage duration shall be initialized (set to their initial values) before program startup.

And if main contains static int arr [5] = {1,2,3,4,5}; then this object must already be initialized when we reach the declaration. So we can only fulfil 5.1.2 if the integer constant 5 in my example, an integer constant expression, is in fact evaluated at compile-time.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • `before program startup.` But "program startup" starts when `main` is called. If the code would be ex. `const int var = {1+2};` then a compiler can generate code `void __my_super_init() { var = 1 + 2; }` to be executed before `main` and _at runtime_ calculate the result. Right? That something is initialized, does not mean it's calculated at compile-time. – KamilCuk Apr 26 '21 at 12:31
  • @KamilCuk On embedded systems with true NVM, all initializers are stored in flash memory and copied down into static storage duration objects before main() is called. This happens in run-time, but before main(). That's why, I suppose, such start-up code is often referred to as the "C run-time" - it enables run-time execution of standard C, but that doesn't mean that other things that aren't necessarily standard C can execute before main(), but also in run-time. – Lundin Apr 26 '21 at 12:38
  • @Lundin The definition of `side effect` questions me as well. The "side effect" == "change in the state of the execution environment". Now: is the "fact of _using hardware_ (ALU)" (for example) considered to be a side effect? Now no. Hence, the C compilers are free to evaluate a certain expressions at compile time. However, if later in the code the users checks "whether the hardware (ALU) was really used?" (which is a side effect), the answer will be unpredictable. Any ideas / thoughts / comments on this? – pmor Jun 07 '21 at 21:41
  • _There are no requirements placed stating that the compiler must perform certain optimizations_: The non-required cases like: _may_, _can_, _might_, _allowed to do_, etc. always confuse me: the standard does not look like a "strict standard: all the implementations must follow", but rather a standard-recommendation: "must for critical / required things, not obliged for all the others". Any ideas, why such state of affairs? I.e. why such high latitude? Maybe to reduce the number of cases, when an implementation cannot fulfill (by some reason) all the requirements? – pmor Jun 07 '21 at 21:54
  • @pmor The definition of side effects is quite straight forward. In terms of hardware, that means memory-mapped hardware peripheral registers, DMA buffers, variables shared with ISRs and so on. Such access needs to be volatile qualified. – Lundin Jun 08 '21 at 06:22
  • 1
    @pmor The reason why so many things are vague and implementation-defined is supposedly (this is was what a former member of the committee told me) that ISO standards are not allowed to favour certain existing technologies so that they get an unfair market advantage or that the standard discourages R&D. That's why C allows strange things like one's complement or signed magnitude signedness for example. – Lundin Jun 08 '21 at 06:27
  • @Lundin Just to remind: _accessing a volatile object_ != _performing operation with such volatile object_. Example: expression `a + b;` (where both `a` and `b` are of type `volatile double`) leads to `unused result`. However, under `#pragma STDC FENV_ACCESS ON` evaluation of such expression leads to side effects. However, even "`__STDC_IEC_559__ 1` compilers" can remove execution of `+` operation and keep only load operations (because they are guaranteed by `volatile`). Example (seems bug in gcc): https://stackoverflow.com/q/67324215/1778275. – pmor Jun 09 '21 at 10:57
  • @pmor Here's an old paper on the subject: https://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf. Basically PC programmers writing compilers is the root of the problem, because PC programmers can't understand how a read could be a side effect. – Lundin Jun 09 '21 at 11:23
  • @Lundin ISO standards are international standards. What about national standards? Is the "not allowed requirement" propagated to national standards as well? P.S. Thanks for the paper. FYI: In https://web.cs.ucdavis.edu/~su/emi-project/ authors claim that EMI-based testing is more efficient than differential testing (ex. using randprog / csmith). – pmor Jun 11 '21 at 13:03
  • @Lundin About "`volatile double` example". Here is the exact example showing bug in gcc: https://godbolt.org/z/6GnqTYvaa. – pmor Jun 12 '21 at 10:27
  • @Lundin See UPD20230711. Any comments / thoughts? – pmor Jul 11 '23 at 09:48