+ gcc чт, 4 дек. 2025 г. в 12:56, Александр Поваляев <[email protected]>:
> 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. > 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 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 >> >>>>> >> >>>> >> >>> >> >>> >> > >> >>
