Source-Changes-D archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/kern
On Thu, Nov 07, 2019 at 13:59:37 +0100, Kamil Rytarowski wrote:
> On 07.11.2019 13:48, Valery Ushakov wrote:
> > On Thu, Nov 07, 2019 at 13:37:21 +0100, Kamil Rytarowski wrote:
> >
> >> On 07.11.2019 13:17, Valery Ushakov wrote:
> >>> On Thu, Nov 07, 2019 at 06:02:39 +0100, Kamil Rytarowski wrote:
> >>> As a side note - the C99 standard contains "derefer" exactly once, in
> >>> a footnote. Since we have ended up in the darkest corners of
> >>> legalistic exegesis, please, can we avoid using the word that is,
> >>> technically speaking, meaningless as far as this discussion is
> >>> concerned?
> >>
> >> Unary * oprator. C++ specified term "dereferenceable" in the context of
> >> the unary * operator.
> >
> > This is C code and the C standard is hard enough as it is already.
> > Please, can we put the C++ aside for a moment?
>
> No. The kernel was already patched (years ago) to build as a valid C++
> software.
"No" what? This is C code. If it also happens to be a valid C++
code, good for it, but that is a separate matter. There's a claim
made about that code that it triggers UB according to the C standard.
That claim can be meaningfully dicussed in that legal(ese) framework
only.
Only after the meaning of the competing claims about that code is
clarified within its "native" framework can we consider C++
interpretation of the same code as a followup and whatever interplay
there is between the standards.
So, if that code is supposed to be valid C code *and* valid C++ code,
then it should be at least valid C code and so, please, can we for now
stick to that part of the "and"?
-uwe
Home |
Main Index |
Thread Index |
Old Index