Re: A: a new bug to old plain C

+ gcc-help

сб, 29 нояб. 2025 г. в 21:27, Александр Поваляев <[email protected]>:

> 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.
>>
>