This has been explained to you repeatedly, by many people, on both the
gcc help list (which is for people asking for help about gcc, not for
people needing help with the C language) and the gcc developers list
(which is for discussing gcc development and is totally inappropriate
for your posts).
It has been explained to you, repeatedly, that the C standards could not
and do not have a list of "explicitly prohibited" conversions. They
have a list of /allowed/ conversions. You have been directed to these,
with chapter and paragraph numbers and direct quotations from the
standards. The conversion you want is not allowed in C as of C23 (and
before), though it is allowed in C++ and will likely be allowed in
future C versions. The C standard term for "not allowed" here is
"constraint violation". In C, /nothing/ is allowed unless it is
explicitly allowed in the standards.
It does not matter if your use of this conversion is "safe" and gives
correct working code with some compilers, or when you add explicit casts
to your C. What matters is that the rules of C do not allow it.
Countless things can be considered "safe" and are yet not allowed by the
C standards.
When a conforming C compiler encounters a constraint violation - such as
in your code - it is required to "issue a diagnostic". This typically
means either a warning message (continuing compilation) or an error
message (halting compilation). A compiler implementation can choose
either strategy. Some compiler implementations will choose one, others
will choose a different option - both are allowed. Good compilers
(including gcc and clang) offer command-line options to let you override
the compiler's default actions here.
So it is fine that clang gives a warning and continues compilation. It
is also fine that gcc gives an error and halts compilation. (As a
general rule, I believe compilers should be strict by default but allow
less strict modes by compiler flags, so I personally prefer gcc's
approach.)
Neither gcc, clang, or any other compilers you tried have a bug here
(unless they didn't even give a warning).
No matter what any compiler does with your code, your C code is
incorrect - it has a constraint violation.
This has all been explained to you several times. It is quite apparent
that you do not have familiarity with the C standards - the definition
of the language. You are either incapable of understanding them, or
have not bothered trying - despite being spoon-feed the relevant
sections. (No one expects you to read the entire standard.) You are
not qualified to judge what is and is not allowed in C, or what is or is
not a bug in a compiler. You can have your opinions, but they are not
qualified or informed opinions, and as such they are worthless to
everyone else. (A qualified and informed opinion would be "I know this
is not allowed in C, but I think it should be".)
You should come away from all this with certain facts:
1. The conversion you want is not allowed in C.
2. It is extremely easy to write C code that /is/ valid, and works
exactly as you want - add an explicit cast.
3. GCC is never going to consider this behaviour a bug, and is never
going to change its behaviour here.
I sincerely hope you understand facts 2 and 3 here.
You can continue to beat your head against the wall claiming that 1
above is not true. As long as it is your own head in the privacy of
your own room, go for it. It won't change reality.
No one can force you to understand this. But I hope that you can
appreciate that your continued posts are a waste of everyone's time, and
the practical way forward is just to change your code and stop posting
on these mailing lists. I don't think anyone will particularly care if
you go away thinking "we agree to disagree", or even "they are wrong but
won't admit it" - just as long as you go away.
Please let this be an end to these posts to the gcc mailing lists. If
you want to email to me personally, go ahead - I am willing to try again
to explain things to you if it stops you from wasting the time of
thousands of list members. But if you continue, then it is perhaps time
for the list administrators to consider blacklisting you (I know that is
a step they are always very reluctant to take).
On 03/12/2025 07:38, Александр Поваляев via Gcc wrote:
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
