Re: You still are in the "cleanup" mentality.
Re: You still are in the "cleanup" mentality.
Posted Dec 30, 2014 20:34 UTC (Tue) by ldo (guest, #40946)In reply to: Re: The problem is with cleanups which should *never* be executed, unless an error happens. by cesarb
Parent article: The "too small to fail" memory-allocation rule
That’s right. You keep insisting that “cleanup” and “rollback” are entirely different, whereas they are really two aspects of the same thing, and can be treated as such.
> That doesn't help with the situation in question, where the memory
> allocation routines never return "failure".
Returning NULL from an allocation request is a failure.
> Sure, you *called* the code unconditionally, but it doesn't change
> the fact that it *executes* conditionally.
Do you know what “abstraction” means?
Posted Dec 30, 2014 22:33 UTC (Tue)
by cesarb (subscriber, #6266)
[Link] (1 responses)
Please, reread the article this comment thread is attached to.
The whole issue is that, under certain conditions, the allocation requests were *never* returning NULL, even when they should!
> > Sure, you *called* the code unconditionally, but it doesn't change the fact that it *executes* conditionally.
Please, reread the article this comment thread is attached to.
Abstraction or not, it doesn't change the fact that, since the allocation requests were *never* returning NULL, even when they should, the error handling code was *never* being executed. It doesn't matter whether it has been abstracted away or not, untested code is untested code.
Posted Dec 31, 2014 21:00 UTC (Wed)
by ldo (guest, #40946)
[Link]
Which is why I am advocating simpler error-handling paths, as in my example.
Re: You still are in the "cleanup" mentality.
> Returning NULL from an allocation request is a failure.
> Do you know what “abstraction” means?
Re: requests were *never* returning NULL, even when they should!