[Development] QtCore missing check for memory allocation

[Oswald Buddenhagen]

On Mon, Mar 02, 2015 at 10:11:33AM -0800, Thiago Macieira wrote:
> On Monday 02 March 2015 11:21:10 Oswald Buddenhagen wrote:
> > > I am actively against it while it's a huge burden on us for little
> > > perceived  benefit. You have to convince me of the benefit against the
> > > cost.
> > 
> > i still don't see that huge burden. i see introducing a few (inline)
> > functions in two alternative #ifdef branches, and a global search &
> > replace operation.
> 
> You need to replace all the "new" too for this to be effective.
> 
this aims at the reliably failing builds without exception support, so
the non-throwing new's return value would have to be checked to
complement the malloc wrapper.

while this would be reasonably simple (just replace new with qNew or
something like that), it would be a) kinda ugly and b) would expand to
lots of code.


the other case is a build with exceptions where new throws as normal and
qMalloc (used from c++ code) throws as well. malloc calls from c code
would obviously need to handle and propagate malloc failures up to a
point where we can see them and throw, which isn't much effort for our
own code.

however, there is a serious problem: stack unwinding resulting from
an exception being thrown (even if it just aborts in the end because
nobody catches it) requires all objects on the stack to keep their
internal state consistent enough so that invoked d'tors won't crash -
even when a c'tor throws before initialization finishes.
this is clearly at least partially the exception safety which we have
deemed out of scope so far because of an unreasonable cost/benefit
ratio. i presume we're not going to change our opinion on that point.


regarding 3rd party libraries: some would need to be excluded from the
support entirely (because they are uncooperative), while others may need
fixes inside or around the libs. generally, whether they return null or
throw (while being exception-safe) doesn't matter, as the mechanisms can
be translated into each other. i don't think the effort for that would
be prohibitive if we had a serious interest in it, but it certainly
wouldn't come for free.


so to summarize ... color me convinced. replacing malloc it is.