Il 10/05/2013 16:39, Anthony Liguori ha scritto: > I just oppose the notion of disabling casts and *especially* only > disabling casts for official builds.
This actually happens all the time. Exactly this kind of type-safe cast is disabled in releases of GCC, but enabled when building from svn trunk. I have hardly seen any of these failures _during development_, much less on a release. I appreciate the advantage of type-safe casts, but in QEMU they are a solution in search of a problem. They are cheap to implement (though not that cheap to execute ;)) so it's perfectly fine to have them, but they are not _needed_; disabling them is anyway a good build-time option to have. Type-safe casts make sense in GTK+/GObject where: 1) type-safe casts return NULL and log a "critical" error, they do not abort; 2) all functions fail with another "critical" error if they are passed NULL. We do neither, so we're just trading a crash now for a crash very soon after (our call stacks tend to be relatively shallow, with some exceptions such as the block layer). Also, in GTK+/GObject the code paths are unpredictable because they depend on user interaction, and a crash can lead to data loss. By contrast, in QEMU most of the code is hardly ever run, and the possible paths are very few because driver writers tend to use always the same path. The day someone is bringing up a new guest OS and encounters such a crash, we'll tell them to either build from git, or to use --enable-qom-cast-debug. I'm sure it will be a long time before that happens... Paolo > Regards, > > Anthony Liguori > >>> Either way, it would be nice to see the call sites of those >>> most-impacting dynamic casts! So far I held back my APIC RFC since I'm >>> not sure how to reproducibly profile things. >> >> It's interrupts (both sending and returning from them). >> >> Paolo > > >
