On Fri, Feb 27, 2015 at 09:26:14AM -0800, Thiago Macieira wrote: > On Friday 27 February 2015 09:20:54 Oswald Buddenhagen wrote: > > the whole point would be *not* using unwrapped malloc and new(nothrow). > > this can be trivially verified for our own code with a grepping bot. > > There's an easier solution. > replacing system functions seems a bit messy. but whatever.
on the "receiving side", i guess a signal handler that longjmp()s out of signal context is about equivalent to a catch block, so it should be a workable solution. > > > The argument is that chain is as strong as its weakest link. If we don't > > > fix all the holes, the bucket will still leak (pardon my switch of > > > metaphors). > > you can let this be somebody else's worry. our task is to enable a use > > case, not to make it bullet-proof ourselves. the first step is not being > > actively hostile to it. > > 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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development