Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in <asm/msr.h>

["H. Peter Anvin" <hpa@zytor.com>]

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