Places where we have const* arguments in source, optionally mark the value as const as well.

[ahsonkhan]

Used this regex:
const\* (?!const) -> const* const on *.c files excluding sdk\tests, sdk\samples, and intentionally skipping *.h files

[momuno]

Side Q: I'm intrigued that this compiles without changing header declarations. Do you know why that is?

[ahsonkhan]

Side Q: I'm intrigued that this compiles without changing header declarations. Do you know why that is?

I will quote @BillyONeal

in C, f(char*) and f(char* const) are the same function

I don't know the underlying compiler or language reason to exactly why that is (or the mechanism behind it), but if I had to guess, the generated assembly is going to be identical and the second const is just an implementation detail hint used by the compiler in some way to validate assignments.

[BillyONeal]

I don't know the underlying compiler or language reason to exactly why that is

C11 6.7.6.3 "Function declarators (including prototypes)"/15:

The part I highlighted says that type qualifiers are removed from the declared type when determining whether function types are compatible. Note that the const in const T* is not a qualifier on the pointer's type, it's on the pointee's type. C only strips the top level qualifier, it doesn't "reach inside" to remove the inner const.

[momuno]

I don't know the underlying compiler or language reason to exactly why that is

C11 6.7.6.3 "Function declarators (including prototypes)"/15:

The part I highlighted says that type qualifiers are removed from the declared type when determining whether function types are compatible. Note that the const in const T* is not a qualifier on the pointer's type, it's on the pointee's type. C only strips the top level qualifier, it doesn't "reach inside" to remove the inner const.

Thanks for this info. A spot I'm still a little confused on is the removing of qualifiers to determine if function types are compatible. Here's my question: If the qualifier (in this case const on the pointee) is removed prior to compatibility testing, then wouldn't that make int function_name(int const* var1) the same as int function_name(int* var1) ? However, I have found that the compiler will complain if the decalaration and definition of a function differ in this respect.

[momuno]

@ahsonkhan are you thinking to also update the header files in a separate PR?

[BillyONeal]

If the qualifier (in this case const on the pointee)

Qualifiers on the pointee aren't qualifiers on the function argument, so they are not adjusted by the above wording.

then wouldn't that make int function_name(int const* var1) the same as int function_name(int* var1) ?

No, because the const in "int const*" is not a type qualification of the function parameter. The function parameter's type is a pointer, not a const or non-const int. The const in int *const is a type qualification of the function parameter, since the const refers to the function's parameter, which is a pointer.

[momuno]

If the qualifier (in this case const on the pointee)

Qualifiers on the pointee aren't qualifiers on the function argument, so they are not adjusted by the above wording.

then wouldn't that make int function_name(int const* var1) the same as int function_name(int* var1) ?

No, because the const in "int const*" is not a type qualification of the function parameter. The function parameter's type is a pointer, not a const or non-const int. The const in int *const is a type qualification of the function parameter, since the const refers to the function's parameter, which is a pointer.

Oh I get it now. I had it flipped. Thank you!

[ahsonkhan]

are you thinking to also update the header files in a separate PR?

No. That is intentionally not something we want to do as per our discussion/meeting last Friday. We don't want redundant use of const in the public headers to increase cognitive burden on the end user. Having it optionally used in the source files, to try to validate correctness, is OK.

Quoting @CIPop

In SRC we can have the const on all parameters that are const in this version of the implementation. The public API (include files) do not need to have the consts since they do not affect in any way the application (taking a dependency on our sources).

http://www.gotw.ca/gotw/006.htm
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#exception-49
https://stackoverflow.com/questions/117293/use-of-const-for-function-parameters/11036371#11036371
https://stackoverflow.com/questions/1554750/c-const-keyword-use-liberally/1554820#1554820

[momuno]

are you thinking to also update the header files in a separate PR?

No. That is intentionally not something we want to do as per our discussion/meeting last Friday. We don't want redundant use of const in the public headers to increase cognitive burden on the end user. Having it optionally used in the source files, to try to validate correctness, is OK.

Quoting @CIPop

In SRC we can have the const on all parameters that are const in this version of the implementation. The public API (include files) do not need to have the consts since they do not affect in any way the application (taking a dependency on our sources).

http://www.gotw.ca/gotw/006.htm
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#exception-49
https://stackoverflow.com/questions/117293/use-of-const-for-function-parameters/11036371#11036371
https://stackoverflow.com/questions/1554750/c-const-keyword-use-liberally/1554820#1554820

Sounds good. Tbh, there was so much back and forth, repetition and circling back around in that debate, I wasn't clear on the end result.

[ahsonkhan]

@RickWinter, @ericwol-msft, @barcharcraz, @CIPop - please review.

[ahsonkhan]

Got confirmation from @ericwol-msft offline that this should wait until after GA. Please hold off on merging for now.

[ghost]

Hello @ahsonkhan!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.