Re: Integrating QOM into QAPI

[Christophe de Dinechin <dinechin@redhat.com>]

> On 28 Jan 2020, at 11:03, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Mon, Jan 27, 2020 at 08:05:36PM +0100, Christophe de Dinechin wrote:
>> 
>> 
>>> On 26 Jan 2020, at 16:04, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> 
>>> On Sun, 26 Jan 2020 at 08:10, Christophe de Dinechin
>>> <dinechin@redhat.com> wrote:
>>>> I’m still puzzled as to why anybody would switch to something like
>>>> GObject when there is C++.
>>> 
>>> I'm fairly strongly against using C++.
>> 
>> Just to be clear, so am I ;-)
>> 
>>> C++'s language design
>>> is an "everything including the kitchen sink, lots of "this
>>> is here for back compat but it's a bear trap", lots of new
>>> stuff arriving all the time.
>> 
>> Actually, the new stuff is not that bad, overall.
>> 
>> I do agree C++ is an overly complicated language, and that in
>> practice, there is zero chance of qemu moving to it. But that does
>> not invalidate my point that creating a class in C++ is easier
>> than creating a class in any C-based macro-heavy reinvention
>> of basic OO concepts.
>> 
>> (I write this after having read Paolo’s response, which points
>> out IMO better reasons for GObject, which I will discuss there).
>> 
>>> It's just too big to keep in
>>> your head all at once. C has its faults, absolutely, but at
>>> least it tries to be a reasonably sized vaguely coherent
>>> language.
>>> 
>>> You'd have more luck persuading me we should move to Rust:
>>> at least then we'd get some clear benefits (no more buffer
>>> overrun security bugs) for the upheaval :-)
>> 
>> This is largely a myth as soon as you need to do “your own stuff”.
>> Example: CVE-2019-18960, https://seclists.org/oss-sec/2019/q4/141.
> 
> Calling it a "myth" from from that one data point is not really credible.

A single failure is enough to credibly counter any “no more X” claim ;-)

Also, I carefully qualified that as for “your own stuff”. IOW, if you write
your own buffer management, Rust does not help. Well, dealing with
guest memory forces us to have our own buffer management.

> 
> No language is perfect & such that it can eliminate all possible CVEs.
> Rust *can*, however, eliminate a very large set of bugs which lead to 
> memory corruption in unchecked languages like C/C++.

The Rust hype today eerily reminds me so strongly of the C++ hype
20 years ago. C++ too was supposed to be a safer C. And indeed,
if you stick to the standard library, you _do_ eliminate a very large set
of bugs which lead to memory corruption, leaks, etc in C. So the
claim C++ made was not wrong. The claim Rust makes is not wrong
either. The false sense of safety that some people get from it is.


>  You'll still have
> CVEs to deal with, but they'll be different classes of bugs, or rare
> edge cases like the one you show above.

How exactly was it an “edge case”? From what I saw, it was the most
basic kind of range check, exactly the kind that you see in 99.9% of all
range checks.

> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>