Hi Martin, the rationale behind such discussion is to make people aware of all the possible use-cases. So, a person who is going to update somehow GCC clearly understands all pros and cons. I still don't understand why back-compatibility was broken, taking into account that all the relevant GCC flags have been available for a while to fine tune all the conversion matters. I would be good if "safe type conversion" will be introduced to C standard. It is time to do it, for sure.
Respectfully, Aleksandr G Povaliaev. чт, 4 дек. 2025 г. в 23:40, Martin Uecker <[email protected]>: > > I was not involved in this decision, but I still think that > making the defaults for C stricter is generally the right direction > and I am happy that GCC did those changes. > > > I agree with you though that for the specific case you point out it > was bad and this should be changed (both in GCC and in the C standard), > and ideally should have changed before switching the defaults. > > But I am not sure how this email dicussion is in any way helpful. > > > Martin > > > Am Donnerstag, dem 04.12.2025 um 21:36 +0300 schrieb Александр Поваляев: > > Hi Martin, > > > > I would like to believe in it. > > > > But the trend is right the opposite. 1.5 years ago the default behaviour > of GCC pointers conversion was changed. > > As for me, it added some mess and the description is not straight > forward: > > " > > Type checking on pointer types (-Werror=incompatible-pointer-types)GCC > no longer allows implicitly casting all pointer types to all other pointer > types. This behavior is now restricted to the void * type and its qualified > variations. > > To fix compilation errors resulting from that, you can add the > appropriate casts, and maybe consider using void * in more places > (particularly for old programs that predate the introduction of void * into > the C language). > > " - The section looks like the change of parameter behaviour, but in > reality it changed how type conversion is handled by default breaking > 30years backward compatibility. > > > > The description was also accompanied by a small example (code snippet): > > " > > int > > compare (const void *a1, const void *b1) > > { > > char *const *a = a1; > > char *const *b = b1; > > return strcmp (*a, *b); > > > > } > > " which shows some possible unsafe conversion (Q: why they don't convert > "const void*" -> "const char **a = a1" instead?) but it is irrelevant to > the case which was discussed in this e-mail thread. > > > > Respectfully, > > Aleksandr G Povaliaev. > > > > > > ср, 3 дек. 2025 г. в 16:01, Martin Uecker <[email protected]>: > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > >
