A: a new bug to old plain C

[Matthias Pfaller]

Hello Александр,

I'm truly astonished how you can read any support for your claims in my 
reply to Simon. Didn't you read the other replies I wrote? Do you have 
any idea how many replies I deleted without sending (and why I did so...)?

When there still was usenet and you would have posted to a German 
speaking group the following three things would have happend:

- You would have earned the state "beratungsresistent".
- You would have gotten a "Merkbefreiung" (just look it up in the 
Wikipedia).
- I would have answered several of your messages ago with "Plonk!" 
(again, look it up in the Wikipedia)

The only nice thing about your postings was in the initial phase. I 
learned some subtle nuances of modern C. But we are long past this 
phase... It's a pity that every time this thread is about going to die 
someone (including me) just can't believe that you are just to stubborn 
to accept being in error and tries to explain for the nth time what you 
*refuse* to understand: What you are requesting might be a valid wish, 
but it is not C. Just go ahead, define a new language and call 
it Александр-C (or wait for the next C standard).

But please do not try to interpret any of my messages as something even 
remotely similar to a defense or support of your position!

Matthias

On 11/26/25 4:45 PM, Александр Поваляев wrote:
> Hi Matthias!!! Thank you a lot for jumping in this e-mail thread!
>
> Many compilers (including Intel and Clang and some others) compile 
> "Foo**" -> "const Foo * const * const" conversion without errors.
>
> The rationale why do we need "const" is pretty simple. To make our 
> code more error prone. And so to make some hint to compilers and may 
> be to some static syntax analyzers.
> When I am writing code sometimes I need to specify and restrict 
> behaviour of some functions, to provide and supply something which is 
> usually called INVARIANT.
> Let me post a little example here:
>
> "
> // PRE-CONDITION: ...
> // POST-CONDITION: ...
> // INVARIANT: array 'arg' and all its elements won't be changed
> void subfunc(struct zzz const * const * const arg) {
> if (arg != NULL) {
> printf("%s", "Done!");
> }
> }
> void func(struct zzz ** arr_of_ptr, unsigned count) {
> subfunc((struct zzz const * const * const)arr_of_ptr); // ОК!
> *subfunc(arr_of_ptr);*// CLANG: x86-64 clang (trunk) - WARNING!!!
> // GCC: x86-64 gcc (trunk) - ERROR!!!
> // INTEL: x86-64 icc 2021.10.0 - OK!!!
> // MICROSOFT(c++?): x64 msvc v19.latest - OK!!!
> // POWER64 GCC trunk - ERROR!!!
> // ARM gcc(trunk) - ERROR!!!
> // NOTE: based on godbolt.org <http://godbolt.org>
> }".
>
> There is a function "subfunc" and its INVARIANT is "array arg and its 
> elements won't be changed".
> So, how should I design this part of code?
> Right. One of the way to create a function "subfunc" with a parameter 
> of "Foo const * const * const" type.
> And this is what I am doing.
> So, when the "subfunc" is implemented, I can use it and make a call 
> "subfunc(arr_of_ptr)".
>
> And here is the place where "our conversion under question" comes into 
> play.
> As I noted some of the compilers return an error, some - not. So, this 
> is a gray area.
>
> I can make an implicit conversion like "subfunc((structzzz const* 
> const* const)arr_of_ptr);" and it will work fine.
> So, this is a kind of thing which can be gotten around.
> It looks like a warning, and it might be a warning while compiling 
> (saying, that such kind of behavour is not a good "safe programming"
> practice on something like this). And many compilers do it, they 
> return a warning giving all the necessary information.
> But why some of the compilers return an error????
> While some of our colleagues are still looking through C standard to 
> find out answer.
>
> Is it actually an error???
> What kind of error? Is it logical error? System fault?
> Is it an error just because there is some tricky way to get around 
> 'const' qualifier and make an assignment in the end?
>
> Respectfully,
> Aleksandr G Povaliaev.
>
>
>
>
>
>
> ср, 26 нояб. 2025 г. в 10:19, Matthias Pfaller <leo@marco.de>:
>
>     On 2025-11-26 07:27, Simon Richter wrote:
>     > Hi,
>     >
>     > On 11/26/25 3:14 PM, Александр Поваляев via Gcc-help wrote:
>     >
>     >> Could somebody point out where in the C standard a conversion
>     "Foo**" ->
>     >> "const Foo * const * const" is prohibited?
>     >
>     > It's disallowed because
>     >
>     >     void foo(int const *const p)
>     >     {
>     >         int *nonconst_p;
>     >         int *const *const pp = &nonconst_p;
>     >         *pp = p;
>     >         *nonconst_p = 42;
>     >     }
>     >
>     > would allow overwriting a variable passed in as pointer-to-const.
>     >
>     >    Simon
>
>     Sorry Simon,
>
>     *pp = p;
>
>     would not be possible because "*pp" is marked as const  in the
>     declaration of pp. It
>     really hurts that I have to pour additional fuel into the fire...
>
>     regards, Matthias
>