Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in

H. Peter Anvin
2025-04-10T01:38:13Z

On 4/9/25 14:55, Xin Li wrote:
>
> It looks to me that we don't use the "const" qualifier in the code a
> lot.  However since the MSR index is usually not expected to change
> inside the MSR API implementations, would it be nicer to add the "const"
> qualifier?
>
> The same to the MSR value of MSR write APIs.
>

"const" on an automatic variable (including function arguments) is
usually not very meaningful, unless it is manifest as a memory object
(see below.)

Personally I tend to use "const" anyway in more complex functions to
make it clear that a variable is not expected to change while in scope
(and I also prefer to reduce the scope of a variable as much as
possible), but for a simple function like this it is more clutter than
anything else.

Now, "const" on a *memory object* (pointer target) is a very different
thing and should in general be used where ever writing to an object is
not going to happen.

An automatic variable becomes manifest as a memory object if its address
is taken anywhere in its scope (using the & operator or an unindexed
array) and the address of that pointer stored. The last part means that
the compiler (if it is is smart enough) can take a sequence of
operations equivalent to *& and eliminate it.

Keep in mind that, for C (not necessarily C++):

1. in *all* cases "foo[x]" is exactly equivalent to "*(foo + x)"
2. *if* "foo" is declared as an array type, then "foo" is exactly
equivalent to "&foo[0]".

"const" in C a little less strict than you would like; the only way in C
before C23 to declare a "true" constant is using enum or a #define macro
(which of course pollutes the global namespace). In block scope it
usually doesn't matter for scalar types and const or static const will
work just fine, but it is only in C23 than C imported "constexpr" from
C++ (which has had it since C++11.)

-hpa