Re: A: a new bug to old plain C

> On 12/09/2025 4:49 AM PST Александр Поваляев via Gcc-help <[email protected]> wrote:
> ...
> But if you skip some of "const", type naming might be less readable and
> understandable.
> 
> All-CONST == CONST INVARIANT == "[IN]PARAMETER".
> 
> Yep, we use 'void Func(int i)' instead of 'void Func(const int i)' cause
> this is how traditions work :)
> ...

But here you are talking about the _function_ _parameter_. Meanwhile, in the 
previous messages we were talking about the _cast_. The cast and the parameter 
are two different things. So, leave alone the parameter for a minute and let's 
talk about the _cast_ itself. 

Since my reference to formal standard concepts seem to gain no traction with 
you, permit me to annoy you a bit more with a couple of my famous "irrelevant" 
examples instead. 

Consider this simple program in C

  int main(void) {
    const const const const int a = (const const const const int) 3.14;
  }

Believe it or not, this a perectly valid C program. (C++ will give you hell for 
this, but it is 100% valid in C.) The language will simply quetly collapse the 
repetitive `const` qualifiers.

However, if you show the above code to any competent C programmer, they will 
probably give you that "WTF?" look in return. And indeed, WTF? I hope you'll 
agree with me: even though the code is valid, the usage of `const` in it is 
somewhat... excessive. Unjustifiably excessive.

So, let's say we decided to dial it down to something more sensible and came up 
with the following variant

  int main(void) {
    const int a = (const int) 3.14;
  }

This looks a lot cleaner. But still... A competent C programmer might reluctantly 
point out the fact that the _cast_ is still somewhat nonsensical. You see, 
semantically there's really no such thing as cast to `(const int)` in C. The 
result of a cast in C is always an Rvalue, and an Rvalues in C cannot be 
const-qualfied. In C top-level `const` on Rvalues is always ignored.

An excessive top-level `const` in a cast is not an error. It is simply quietly 
ignored by the compiler. The compiler immediately sees the above cast as cast to 
`(int)`. But the point is (!) that casting something to `(const int)` is pretty 
much as excessively nonsensical as casting something to `(const const const const int)`.

Again, formally this is not an error, so it is kinda partially drifts into the 
area of personal coding style. I don't know, maybe there are people out there 
who routinely cast things to `(const const const const int)` and believe that it 
helps them to, you know, "drive the point across". But all these variants will 
still be immeditaly reduced by the compiler to a simple cast to `(int)`. All 
top-level const-qualifiers in a cast are immediately discarded by the compiler. 
For this reason, majority of competent C programmers will probably prefer to 
implement the above [contrived] example as

  int main(void) {
    const int a = (int) 3.14;
  }

Note that we do keep the `const` in the variable declaration, it is not redundant 
there. But we omit the `const` from the cast. 

This mirrors your original example: keep the top-level `const` in your parameter 
declaration, nobody's objecting that. But there's just no point in keeping the 
top-level `const` in the explicit cast.

That's the point I was making. Nobody's trying to attack your "const invariance" in 
your parameter declaration. It was about the _cast_ and only about the _cast_. 

-- 
Best regards,
Andrey