As I wrote the parameter was introduced to GCC 5.1. Alongside with " - It is possible to disable warnings about conversions between pointers that have incompatible types via a new warning option -Wno-incompatible-pointer-types; warnings about implicit incompatible integer to pointer and pointer to integer conversions via a new warning option -Wno-int-conversion; and warnings about qualifiers on pointers being discarded via a new warning option -Wno-discarded-qualifiers. - To allow proper use of const qualifiers with multidimensional arrays, GCC will not warn about incompatible pointer types anymore for conversions between pointers to arrays with and without const qualifier (except when using -pedantic). Instead, a new warning is emitted only if the const qualifier is lost. This can be controlled with a new warning option -Wno-discarded-array-qualifiers.".
Respectfully, Aleksandr G Povaliaev. чт, 4 дек. 2025 г. в 18:27, Александр Поваляев <[email protected]>: > 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 >> > > >>>>>>> >> > > >>>>>> >> > > >>>>> >> > > >>>>> >> > > >>> >> > > >> >> > > >> >> > > > >> > > >> > > >> >
