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