A: a new bug to old plain C

[Nicholas Vinson]

On 12/3/25 08:01, Martin Uecker via Gcc wrote:
> 
> I am not sure this has been pointed out, but you can downgrade this
> to a warning with -fpermissive.
> 
> Otherwise, I do not quite I understand the point of this discussion.
> Somebody needs to write a patch downgrading the warning in this
> specific case (but not others that are problematic) to a pedantic
> warning.  I would assume that such a patch would have a good chance
> of being accepted.

The change in behavior for -Wincompatible-pointer-types was intentional.

See https://gcc.gnu.org/gcc-14/porting_to.html. It also discusses how to 
adjust gcc's behavior so it becomes a warning instead of an error again.

Regards,
Nicholas Vinson

> 
> Martin
> 
> 
> 
> Am Mittwoch, dem 03.12.2025 um 15:49 +0300 schrieb Александр Поваляев via Gcc:
>> Hi David! Thank you a lot for your time and postings!
>>
>> I agree that it should be an option and it should be a developer decision
>> whether to turn on/off pedantic errors.
>> But as for now, we have no option whether to treat such conversion ("Foo**"
>> -> "const Foo * const * const") as an error or warning.
>>
>> Up to version 13.4 GCC x86-64 also treats it as a warning by default.
>> So, if you compiles the following code snippet with x86-64 gcc 13.4 (
>> godbolt.org was used)
>> "
>> struct zzz {
>> unsigned x, y;
>> };
>>
>> void subfunc(struct zzz const * const * const arg) {
>>
>> if (arg != NULL) {
>> printf("%s", "Done!");
>> }
>> }
>>
>> void func(struct zzz ** arr_of_ptr, unsigned count) {
>>
>> subfunc(arr_of_ptr);
>> }
>> "
>> you will get only the warning.
>> So, starting from version 3.4.6 up to version 13.4 gcc x86-64 DOES provide
>> an option for decades.
>>
>> But then SOMETHING happened to version 14.1 of gcc x86-64, so it started
>> returning an error.
>> It BROKES BAKE COMPATIBILITY of safe conversion without any reasoning. Is
>> that right?
>>
>> The same change of default behaviour (when converting "Foo**" -> "const Foo
>> * const * const") is observed within POWER gcc compiler:
>> it treated it as a warning starting from version 4.8.5 until the version
>> 13.4. Starting from 14.1 POWER GCC returns an error.
>> And the same story with versions happens for ARM GCC...
>>
>> ---------------------------------------------
>>
>> The interesting fact is that if you add "-std=c90 -pedantic" compiler
>> options, all the versions will work FINE! returning a warning.
>>
>> So, the BUG IS ABOUT CHANGING OF DEFAULT GCC BEHAVIOUR WHEN CONVERTING
>> "Foo**" -> "const Foo * const * const".
>> IT BROKES BACK-COMPATIBILITY WITHOUT ANY VISIBLE REASON AND IT SHOULD BE
>> FIXED!!!
>>
>> Respectfully,
>> Aleksandr G Povaliaev.
>>
>> P.S. This e-mail would be much shorter if it had been less irrelevant
>> examples and proofs.
>>
>>
>> ср, 3 дек. 2025 г. в 12:02, David Brown <david.brown@hesbynett.no>:
>>
>>> 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 <atarasevich@comcast.net>:
>>>>
>>>>> 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
>>>>>
>>>>
>>>
>>>
>