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