Re: A: a new bug to old plain C

Hi Jonathan :),

Truly speaking, I don't know what happened to change default behaviour for
type conversion. All these things have been known for 30years, many times
discussed and stabilized (in according to C standard, its warnings and
different levels of "pedantism").

Usually, C language is being used by a person who clearly understands what
he is doing and why.
C language is not a Python or Go, or Rust.
So, I don't think it makes additional sense to "protect" the person from
some possible unsafe conversions somehow.

I am an experienced person and when I'm going to make "Foo**" -> "const Foo
* const * const" conversion, I do clearly understand what I am doing.
And this is the real use-case from my practice which I use quite often.
If you are afraid of possible unsafe using of type conversion, you may
switch to Java or C#. It doesn't make sense to implement OS kernel or
driver real-time extensions if you feel you might be doing something wrong
or unsafe in your program. And for sure, it doesn't make sense to rely of
GCC warnings :)

Respectfully,
Aleksandr G Povaliaev.





сб, 6 дек. 2025 г. в 02:48, Jonathan Wakely <[email protected]>:

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