Hi Richard, Thank you for the link!
I can see there is a section discussing the compiler parameter "-Werror=incompatible-pointer-types". The parameter has been known for some time (so as "-Wno-error=incompatible-pointer-types") since GCC 5.1. And this parameter allows to tune GCC compilers fine instead of using '-pedantic-errors'. Respectfully, Aleksandr G Povaliaev. чт, 4 дек. 2025 г. в 17:29, Richard Biener <[email protected]>: > On Thu, Dec 4, 2025 at 2:43 PM Александр Поваляев via Gcc > <[email protected]> wrote: > > > > Hi David! > > > > I don't think "Fatal error" is an appropriate term for "Foo**" -> "const > > Foo * const * const" conversion. It has been here for decades (30 or 40 > > years) as a warning. > > And some of the compilers don't report it as a warning by default (please > > see the code snippet with the comments I posted to this e-mail thread). > > > > Once again, converting a warning which has been known for 30 years to a > > "Fatal Error" by default is the wrong way. IT BREAKS 30 YEARS BACK > > COMPATIBILITY!!! > > And as somebody wrote here, now it is on the way to become part of C > > standard (and it would be quite logic outcome), but not a "Fatal Error" > as > > you wish. > > > > WHO DISCUSSED THESE CHANGES? > > WHERE THESE CHANGES ARE DOCUMENTED? > > ARE YOU TALKING ABOUT SOME REAL THINGS? > > IF YES, COULD YOU PLEASE BE SO KIND TO POST A LINK. GREAT THANK YOU IN > > ADVANCE!!! > > https://gcc.gnu.org/gcc-14/porting_to.html > > > Respectfully, > > Aleksandr G Povaliaev. > > > > чт, 4 дек. 2025 г. в 16:09, David Brown <[email protected]>: > > > > > On 04/12/2025 10:56, Александр Поваляев via Gcc-help wrote: > > > > Hi David! > > > > > > > > Even if a software (like gcc) is open-source, it still can be used > for > > > > commercial purposes. So, it is not always just for education and > > > > open-source experiments. > > > > > > Nobody suggested that is the case. Open source software has never been > > > about "just education and experiments" - it has always been used > > > commercially as well as non-commercially. The same applies to GCC, > both > > > the compiler itself and programs compiled with it. > > > > > > > Taken seriously, backward compatibility is a very important property. > > > > "Foo**" -> "const Foo * const * const" conversion has been allowed > for > > > > decades (20x or 30x) by default and, I truly speaking, don't know > what > > > > happens to it about a year ago. > > > > But Gcc ver 14 (https://gcc.gnu.org/gcc-14/) which was released at > > > > 2024 silently decided to stop it. > > > > > > It was not silently changed. The conversion was /always/ a C violation > > > - it was /always/ a bug in your C code. With gcc 14, a number of > > > violations that previously only triggered a non-fatal warning message > by > > > default, where changed to trigger fatal error messages. The change was > > > not silent - it was documented in the reference manual that you should > > > have read before changing to a different compiler version. > > > > > > The gcc developers made this change, knowing that it might affect some > > > people - but after checking that it probably affects very few people. > > > > > > > > > Development practices vary from project to project, and company to > > > company, and there is no "right" way to work. But I can't help feeling > > > that to be in the position you are now requires a failing of several > > > things that I would seriously question: > > > > > > 1. You appear to have updated your key development tools without > testing > > > them or considering the effects the updates would have. You have not > > > read the changes information or the porting guides. > > > > > > 2. You do not understand all of the details of the C language standards > > > (few people do), but you /think/ you understand them and refuse to > > > accept help, information and correction from people who know them > > > better. Instead of asking for support and help, you accuse others of > > > having bugs in their code. > > > > > > 3. You do not appear to care that your code works because it is correct > > > and valid, only that you can compile it and test it. > > > > > > 4. You do not take compiler warning messages seriously, and appear to > > > ignore them as "just warnings" - only when there is a fatal error > > > message do you pay attention. Good development practice is to use > > > whatever static error checking you can practically use for the project, > > > including many compiler warning flags, and to take /every/ warning > > > seriously. A mature project (or your "master" branch) should build > > > cleanly, without warnings, when using tested and approved compiler > > > versions and flag setups. > > > > > > 5. You would rather waste an inordinate amount of your own time, and > > > that of a large number of other people, by posting the same > > > misconceptions repeatedly in mailing lists over a period of weeks, > > > rather than adding a one-line correction to your code. Are you > charging > > > some customer for this "work" ? > > > > > > 6. You are using tools that you don't understand, without reading the > > > manual, and disregarding the expert information given to you by the > > > people who wrote the tools. Case in point - "I am sure compilation > > > flags are not the cure-all to all the possible cases", despite the gcc > > > 14 porting guide clearly stating the flags needed to get the old-style > > > behaviour, despite the compiler giving you clear information about the > > > flags related to the error, and the gcc manual documenting the flags, > > > and gcc users and developers giving you information about the relevant > > > flags. > > > > > > > > > I don't see this compiler change affecting other projects, commercial > or > > > not, in the same way, because I think it is unlikely for development > > > groups to fail on all these points. And I think that most developers > > > who come across this and ask for help, will accept and appreciate the > > > help they are given, correct their code, and move on. > > > > > > But then, it is unusual to come across developers who are as stubbornly > > > and wilfully ignorant and yet so utterly convinced of their own > > > understanding. That is not a trait conducive to a successful career in > > > software development. > > > > > > > > > > > > > > > > > It might be the case that somebody wanted to prohibit explicit > conversion > > > > "Foo**" -> "const Foo ** const" (or other unsafe type of conversions, > > > which > > > > was mentioned in this e-mail thread) and made > > > > some changes to GCC source code. And that changes also "broke" safe > > > > conversion "Foo**" -> "const Foo * const * const" making it produce a > > > > compilation error. > > > > And I don't think that somebody intentionally changed it (within > > > > appropriate discussion and explanations). > > > > So, it is a BUG just because it was appeared and made > unintentionally :) > > > > > > > > And for sure it should be FIXED because we now all (thanks GOD!) > agree > > > that > > > > such conversion ("Foo** -> const Foo * const * const") is safe and > > > useful. > > > > So, we are actually talking about of "REVERTING" some changes which > was > > > > made by error :) > > > > > > > > Since Gcc ver 14 was released almost 1.5 year ago, it might be the > case > > > > that not all the commercial projects have migrated to it yet and so > they > > > > (projects) don't still know about this new behaviour. > > > > And truly speaking it looks very strange and abnormal when after > > > migrating > > > > to a newer version (after decades of work) the projects have their > > > > compilation broken, and the source code needs to be updated just to > make > > > it > > > > work (because I am sure that compilation flags are not the cure-all > to > > > all > > > > the possible cases). > > > > > > > > Respectfully, > > > > Aleksandr G Povaliaev. > > > > > > > > > > > > > > > > > > > > > > > > ср, 3 дек. 2025 г. в 23:05, David Brown <[email protected]>: > > > > > > > >> > > > >> I don't agree that such a patch is a good idea. > > > >> > > > >> This is just my 2 cents worth, as a gcc user rather than a > developer. > > > >> And I am one of these unusual C programmers that reads the new C > > > >> standards whenever they come out, and reads the gcc manuals, lists > of > > > >> changes and porting guides, and picks a compiler version and set of > > > >> flags and options that suits me and the requirements of the > projects. > > > >> So default settings do not affect my own work significantly, and I > will > > > >> be a happy gcc user no matter what is decided. > > > >> > > > >> But I believe an aim of gcc is to help developers write good quality > > > >> code (in various languages, but C is the language in question here) > as > > > >> well as giving them efficient object code compiled from that source > > > code. > > > >> > > > >> I think gcc should aim to be as standards compliant as practically > > > >> possible, out of the box. And it should be as fussy as possible > about > > > >> clearly incorrect code or clear UB, by default. Of course it is > limited > > > >> by backwards compatibility, just like the C language itself - > changes > > > >> that lead to new warnings and errors on existing working code need > to be > > > >> made with due consideration. > > > >> > > > >> No matter how much we may all agree that using the conversion > discussed > > > >> here is safe (at least in the code in question), it is a constraint > > > >> violation in today's C. I don't believe it is a good idea for > anyone - > > > >> C programmers or C compiler implementers - to unilaterally decide > that > > > >> their particular non-conforming variant of C is the "right" version. > > > >> That makes a mockery of the whole concept of a standard language. > It's > > > >> fine for individual developers to choose what they want for their > own > > > >> projects, but a compiler implementation should not make those > choices > > > >> for other people. > > > >> > > > >> It is unfortunate, IMHO, that the default "standard" used by gcc is > a > > > >> gnu-specific variant of C. (I say that as someone who actively > chooses > > > >> -std=gnuXX, as being a better choice for my own usage.) It is more > > > >> unfortunate still when the variations in the -std=gnuXX versions are > > > >> contrary to the C standards, rather than just extensions. I don't > > > >> expect this will ever change, but at least I would ask that gcc > > > >> developers avoid actively making changes that make it easier to > write > > > >> non-standard C, or other clear errors (gcc can detect more UB than > just > > > >> constraint violations), without the developer having to decide to > use > > > >> options to get the behaviour they want. > > > >> > > > >> The historical lax behaviour of many compilers (not just gcc), > followed > > > >> by the push for compatibility with existing code, means that a great > > > >> deal of C code written today is of far poorer quality, and has many > more > > > >> bugs, than it need do. The more we can help people find their > errors > > > >> sooner, the better - especially for developers that are perhaps not > as > > > >> familiar with C programming or using tools like gcc in the best way > they > > > >> can, and thus using more of the default settings. > > > >> > > > >> The changes of diagnostic priorities in gcc 14 were, as I see it, a > good > > > >> step forward. I'd like to see more of such changes, not having the > > > >> changes undone - even in this relatively minor case, and even > though we > > > >> expect the conversion to be valid in -std=c2y. > > > >> > > > >> > > > >> As I said, this is just my own personal opinion, and the decisions > for > > > >> these things rests with people who are far more familiar with gcc > and > > > >> it's wider users and uses than I am. > > > >> > > > >> David > > > >> > > > >> > > > >> > > > >> On 03/12/2025 14: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. > > > >>> > > > >>> 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 > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>> > > > >> > > > >> > > > > > > > > > > >
