On Thu, Jul 13, 2000 at 07:03:18PM +0200, Andi Kleen wrote:
> The alternative is the error prone and ugly:
>
> if (a = alloca()) {
> if (b = allocb()) {
> if (c = allocc()) {
> if (d =allocd()) {
> do_real_work();
> freed(d);
> }
> freec(c);
> }
> freeb(b);
> }
> freea(a);
> }
This one would _easily_ conflict with 8 space tabbing (required
for Linux Kernel coding style).
> which is IMHO just asking for obscure bugs in error paths.
>
> /* a b c d are NULL */
> a = alloca();
> b = allocb();
> c = allocc();
> d = allocd();
> if (a && b && c && d)
> do_real_work();
> freea(a);
> freeb(b);
> freec(c);
> freed(d);
>
> Which one do you prefer ?
A third one (usally the one used in the kernel ;-)):
{
void *a,*b,*b,*c;
a = alloca();
if ((b = allocb()) == NULL) goto free_a:
if ((c = allocd()) == NULL) goto free_b:
if ((d = allocd()) == NULL) goto free_c:
do_real_work();
freed(d);
free_c:
freec(c);
free_b:
freeb(b);
free_a:
freea(a);
}
I'm used to failed allocations. And goto is _perfect_ for
aggregated cleanups ;-)
Why? We have the same with locks, which we _don't_ know, if they
are already up()/unlock()ed. If you use counted semaphores to
assign places in queues you notice that _easily_, because you
have a greater count than the length of the queue.
And there are other examples, where alloc/free of a ressource is
semantically a block structure, which can _not_ determine the
"correct" block level.
Regards
Ingo Oeser
-- Feel the power of the penguin - run linux@your.pc <esc>:x- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:17 EST