Hi there! You have done some homework, but you're still on the wrong path.
Once again. It might be unsafe making the following type conversion, like "Foo**" -> "const Foo** const". And many compilers like x86-64 icc 2021.10.0 (Intel Compiler) produce a warning: "warning #167: argument of type "struct Foo **" is incompatible with parameter of type "const struct Foo **const". But it is a WARNING (which warns a developer of possible unsafety), not an ERROR. In our case, we're doing "Foo**" -> "const Foo* const * const" conversion. It is a safe conversion, and the same compiler, x86-64 icc 2021.10.0 (Intel Compiler) compiles it without either error or warning. So, when it might be possibly unsafe, a compiler is free to make a warning (and such cases have been highlighted in this e-mail thread, see https://cigix.me/c23#6.5.17.2.p6). But my request is about is a safe conversion, "Foo**" -> "const Foo* const * const", and so, there is no argument why it is interpreted by some compilers as an error. Here, I would like to synchronize that we are all on the same page, talking about the same things, not about some weird not-relevant examples. So, it is quite a straigh-forward way that C standard doesn't prohibit explicitly doing the safe conversion. Respectfully, Aleksandr G Povaliev. чт, 27 нояб. 2025 г. в 14:29, LIU Hao <[email protected]>: > 在 2025-11-27 18:28, Александр Поваляев 写道: > > 2) Second, there is no explicit prohibition of such conversion ("Foo**" > -> "const Foo*const*const) in C > > standard. > > How hard for you would it be to comprehend that the paragraph which starts > with 'one of the following > shall hold' has a bold word 'Constraints' in front of it so your code is > identified as a constraint > violation and is such undefined behavior? > > Oh maybe you are not willing to read the standard so I quote it for you: > > 5.1.1.3 Diagnostics > 1 A conforming implementation shall produce at least one diagnostic > message > (identified in an implementation-defined manner) if a preprocessing > translation unit or translation unit contains >>>>>>> a violation of > any > syntax rule or constraint <<<<<<<, even if the behavior is also > explicitly > specified as undefined or implementation-defined. Diagnostic > messages need > not be produced in other circumstances. > > > > 3) Half of well-known compilers don't treat such conversion ("Foo**" -> > "const Foo*const*const) as an > > error. They might show a warning or doesn't show it. > > It's undefined behavior so compilers are free to accept it (with a > warning) or reject it (with an error). > > > > 4) I showed a use-case where such conversion might be useful and why. I > think all the participants have > > read that post. > > I understand it's useful. Right. But no matter how weird it looks, it's C. > The standard says it's > undefined behavior, and what you think does not matter, at, all. > > > > 5) IF WE ARE TALKING ABOUT UNIFYING OF C STANDARD IMPLEMENTATION OVER > ALL THE COMPILERS AVAILABLE, WE > > CAN'T MAKE A PROHIBITION AS A GENERAL RULE, SINCE > > WE WILL FACE OUT BACK-COMPATIBILITY ISSUE WITH THE COMPILERS WHICH > HAVE ALREADY HAD SUPPORT OF SUCH > > CONVERSION. > > So it seems that you are unable to agree with what others agree, you are > proactively violating the C > standard, and you are claiming that your disability is causing *your* > issue. Oh, maybe that's just you. > > > > -- > Best regards, > LIU Hao >
