Hi there! Thank you for being on it!
You've written quite a lot of messages and replies. Thank you again for
this.
However, I still don't see how you're proving that such a kind of
conversion must be rejected by any C compiler within an error.
Liu previously tried to do it (to provide logical reasoning), but his prove
lacks some logical consistency.
And so, I don't see that such conversion ("Foo**" -> "const Foo * const *
const) is NOT explicitly prohibited by C standard.
And still there is no sign that what is not explicitly prohibited by C
standard should end up with a compiler error.
Per my understanding, an error "diagnostic" message should be present only
if there is a possible way of getting the program working wrong or leading
to fault.
And a warning "diagnostic" message should be present if there is a possible
way of unsafe behavior.
But in our case, a conversion "Foo**" -> "const Foo * const * const" is an
absolutely safe way of coding.
This is the reason why commercial compilers (like Microsoft/IBM and Intel)
DO support such a kind of conversion.
And so this is an artefact.
It appears when an absolutely safe way of coding which is not explicitly
prohibited by C standard is identified by an ERROR.
I consider such behaviour as a BUG which should be fixed.
This is my attitude.
Respectfully,
Aleksandr G Povaliaev.
ср, 3 дек. 2025 г. в 06:08, Andrey Tarasevich <[email protected]>:
> It looks like we are getting nowhere here... To conclude this "discussion"
> I'll
> reiterate just the relevant points as concisely as I can:
>
> 1. Standard C language does not allow the following pointer conversions as
> implicit conversions:
>
> T ** -> const T *const *
> T ** -> const T *const *const
>
> A program that attempts to rely on such conversions (as implicit
> conversions) is
> invalid, i.e. it contains a constraint violation - a "hard error" in
> standard C.
>
> 2. Compliant C compilers are required to issue diagnostic messages for
> constraint violations. Format and wording of such diagnostic messages are
> not
> standardized in any way. Standard C does not have concepts of "errors" or
> "warnings".
>
> It is your responsibility to figure out that a diagnostic message issued
> for
> this constraint violation indicates a "hard error", provided you possess
> sufficiently pedantic knowledge of C standard. If you don't possess this
> level
> of knowledge of C standard (which is apparently the case in your case),
> but
> still want to write code in standard C, configuration settings like
> `-pedantic-errors` will help you. Moreover, in the latter case, you are
> not
> allowed to even approach C compilers without `-pedantic-errors`. Trying to
> do so
> will only lead to confusion.
>
> 3. If you do not have a "language-lawyer" level of knowledge of C
> standard, you
> do not get to make such bold statements as "I found a bug in C compiler".
> Which
> is well-illustrated by this thread: in this case there's no bug. The
> compiler is
> behaving 100% correctly, despite your claims to the contrary.
>
> 4. As it has been stated repeatedly, there's ongoing work aiming to
> support such
> conversions in future iterations of C language standard. But as of C23,
> these
> conversions are not supported (as implicit conversions).
>
> --
> Best regards,
> Andrey
>
