Re: [PATCH v2 2/4] xdiff/xprepare: refactor abort cleanups

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tay Ray Chuan <rctay89@xxxxxxxxx> writes:

> On Thu, Jul 7, 2011 at 1:57 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Tay Ray Chuan <rctay89@xxxxxxxxx> writes:
>>
>>> Group free()'s that are called when a malloc() fails in
>>> xdl_prepare_ctx(), making for more readable code.
>>
>> Nicer, but I wonder if we can get away with a single label that lets us
>> abort with freeing whatever we have allocated by making sure that the
>> various pointer fields and variables are initialized to NULL, which may
>> lead to even more readable code.
>
> Pardon my dullness. Do you mean to check if the various fields are set
> to NULL upon allocation, and free()'ing them if so?

What I meant was that, instead of doing this:

    func() {
	if (somefunc(&A, ...) < 0)
		goto failA;
        ... do something ...
	B = someotheralloc();
        if (!B)
        	goto failB;
        ... do something ...
	C = yetanotheralloc();
        if (!C)
        	goto failC;
	... do things using A, B, C ...

	return 0;
    failC:
    	free(B);
    failB:
	free(A);
    failA:
        return -1;
    }

it would be easier to follow if you did:

    func() {
	A = B = C = NULL;
	if (somefunc(&A, ...) < 0)
		goto fail;
        ... do something ...
	B = someotheralloc();
        if (!B)
        	goto fail;
        ... do something ...
	C = yetanotheralloc();
        if (!C)
        	goto fail;
	... do things using A, B, C ...

    fail:
        free(B);
    	free(A);
        return -1;
    }

Especially when you have more than 2 such fail labels.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]