Re: A: a new bug to old plain C

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
>