Re: A: a new bug to old plain C

On Wed, 3 Dec 2025, 13:01 Martin Uecker, <[email protected]> wrote:

>
> I am not sure this has been pointed out, but you can downgrade this
> to a warning with -fpermissive.
>

Or with -Wno-incompatible-pointer-conversions

It's been said more than once, but despite insisting on his "logic" and
that he's correct, he doesn't actually read or understand most of the
replies.




> 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.
>
> 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 <[email protected]>:
> >
> > > 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
> > > > >
> > > >
> > >
> > >
>
> --
> Univ.-Prof. Dr. rer. nat. Martin Uecker
> Graz University of Technology
> Institute of Biomedical Imaging
>
>