I am trying to declare a constexpr pointer initialized to some constant integer value, but clang is foiling all my attempts:
Attempt 1:
constexpr int* x = reinterpret_cast<int*>(0xFF); test.cpp:1:20: note: reinterpret_cast is not allowed in a constant expression
Attempt 2:
constexpr int* x = (int*)0xFF; test.cpp:1:20: note: cast which performs the conversions of a reinterpret_cast is not allowed in a constant expression
Attempt 3:
constexpr int* x = (int*)0 + 0xFF; test.cpp:1:28: note: cannot perform pointer arithmetic on null pointer
Is what I'm trying to do not allowed by design? If so, why? If not, how can I do it?
Note: gcc accepts all of these.
C++'s constexpr brings another new dimension to the problem too! It behaves like const in the sense that it makes all pointers constant pointers. But because it occurs at the start of your statement (rather than after the '*') its not immediately obvious.
constexpr creates a compile-time constant; const simply means that value cannot be changed.
A constexpr integral value can be used wherever a const integer is required, such as in template arguments and array declarations. And when a value is computed at compile time instead of run time, it helps your program run faster and use less memory.
As Luc Danton notes, your attempts are blocked by the rules in [expr.const]/2 which say that various expressions are not allowed in core constant expressions, including:
-- a
reinterpret_cast
-- an operation that would have undefined behavior [Note: including [...] certain pointer arithmetic [...] -- end note]
The first bullet rules out your first example. The second example is ruled out by the first bullet above, plus the rule from [expr.cast]/4 that:
The conversions performed by [...] a
reinterpret_cast
[...] can be performed using the cast notation of explicit type conversion. The same semantic restrictions and behaviors apply.
The second bullet was added by WG21 core issue 1313, and clarifies that pointer arithmetic on a null pointer is not permitted in a constant expression. This rules out your third example.
Even if these restrictions did not apply to core constant expressions, it would still not be possible to initialize a constexpr
pointer with a value produced by casting an integer, since a constexpr pointer variable must be initialized by an address constant expression, which, by [expr.const]/3, must evaluate to
the address of an object with static storage duration, the address of a function, or a null pointer value.
An integer cast to pointer type is none of these.
g++ does not yet strictly enforce these rules, but its recent releases have been getting closer to them, so we should assume that it will eventually fully implement them.
If your goal is to declare a variable for which static initialization is performed, you can simply drop the constexpr
-- both clang and g++ will emit a static initializer for this expression. If you need this expression to be part of a constant expression for some reason, you have two choices:
__builtin_constant_p((int*)0xFF) ? (int*)0xFF : (int*)0xFF
. This exact form of expression (with __builtin_constant_p
on the left-hand-side of a conditional operator) disables strict constant expression checking in the arms of the conditional operator, and is a little-known, but documented, non-portable GNU extension supported by both gcc and clang.The reason is the one given by the (for once, very helpful) error message: reinterpret_cast
is not allowed in a constant expression. It's listed as one of the explicit exception in 5.19 (paragraph 2).
Changing the reinterpret_cast
into a C-style cast still ends up with the semantical equivalent of a reinterpret_cast
, so that doesn't help (and again the message is very explicit).
If you had a way to obtain a pointer with value 0
you could indeed use p + 0xff
but I can't think of a way to obtain such a pointer with a constant expression. You could have relied on the null pointer value (0
in a pointer context like you did, or nullptr
) having a value of 0
on your implementation but as you've seen yourself your implementation refuses to do that. I think it's allowed to do that. (E.g. implementations are allowed to bail out for most constant expressions.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With