Hi Andrey,
It looks like you're doing the same thing which this thread contributors
did at the very beginning - trying to use irrelevant comparison and other
type conversion rather than the original request was about.
So, once again: we're discussing "Foo**" -> "const Foo * const * const"
conversion, not "Foo**" -> "const Foo * const *" conversion, not "Foo**" ->
"const Foo**const", e.t.c.
And every "const" in the conversion "Foo**" -> "const Foo * const * const"
DOES make sense.
The use case is pretty simple: we're implementing CONST INVARIANT
(sometimes, in some languages it is depicted as an "IN" parameter, not
"IN/OUT", not "OUT").
And when we are to implement an "IN" parameter, it means the parameter
won't be changed anyhow within the target scope.
In our case the parameter is an array of pointers. And the scope is a
function "subfunc" being called.
So, to make the parameter as CONST INVARIANT, or to "mark" it as an "IN"
parameter, we're doing the following conversion:
"Foo**" -> "const Foo * const * const".
This is how CONST INVARIANT or an "IN" parameter design is being
implemented by means of C language.
Let's take a look at the example mentioned in the e-mail thread closer:
"
void subfunc(struct zzz const * const * const arg) {
if (arg != NULL) {
printf("%s", "Done!");
}
}
".
Parameter "arg" (array of pointers) here is an "IN" parameter (CONST
INVARIANT), so we're trying to guarantee that:
* no structure (struct zzz) which a particular array element is pointing to
will be changed;
* no element of the array will be changed;
* and the pointer to the array itself won't be changed either;
Every of these three constraints corresponds to "const" in the conversion
which we're talking about.
This is the case.
How do you recognize when it should be an error or a warning?
You previously wrote as if it would be almost the same thing. But warning
and error actually not the same thing, you know :D
Respectfully,
Aleksandr G Povaliaev.
сб, 29 нояб. 2025 г. в 10:18, Andrey Tarasevich <[email protected]>:
> No, no, no... You just keep piling up misconceptions.
>
> First and foremost, the third (the last) 'const' in your parameter
> declaration is completely inconsequential in our context (i.e. for
> conversion
> purposes). It is ignored by the compiler. It makes no difference
> whatsoever, which is why I removed it from my minimalistic example - to
> avoid unnecessary clutter. My example is exactly 100% equivalent to
> yours and, of course, exactly as relevant. Mine is just way more compact.
>
> Moreover, your statement "We're discussing 'Foo**'->'const Foo * const
> *const'
> conversion (all-consts)..." is downright nonsensical in formal C
> terminology.
> In C language all conversions produce _rvalues_ (!). Rvalues cannot be
> 'const' in C. Qualifications do not apply to rvalues in C at all
> (see
> https://port70.net/~nsz/c/c11/n1570.html#6.7.3p4). The last 'const'
> in your example, once again, makes no difference and is completely
> ignored by the compiler for conversion purposes.
>
> So, no, we are talking about conversion
> 'Foo** -> const Foo * const *' (note: last 'const' removed as irrelevant).
> And, as I explicitly told you in my first response, this conversion is
> _not_ supported in C language as an _implicit_ conversion. End of story.
>
> (BTW, GCC tends to quote that irrelevant third 'const' in its diagnostic
> messages, while Clang removes it. Take a closer look at Clang's
> diagnostics for your example.)
>
> Your experiments with different compilers and builds are completely
> beside the point. Not sure what point you are trying to make with them,
> considering what has already been explained to you. That said, you did
> find
> a bug in one compiler: in Intel's one. As I have already stated
> previously, Intel's silent behavior in this case is non-compliant. As
> for GCC and Clang... their behavior is perfectly correct: they do issue
> the
> required diagnostic for this constraint violation.
>
> --
> Best regards,
> Andrey
>
> P.S. As it has already been mentioned by other posters, there are
> proposals
> aiming to permit this implicit conversion in C (just like it is permitted
> in C++). But we are not there yet. In C23 your code is still invalid.
>
