linux-kernel - Re: [PATCH] include/linux/slab.h: new KFREE() macro.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 7 Jan 2007 16:02:00 -0800 (PST)
From:	Amit Choudhary <amit2030@...oo.com>
To:	Vadim Lobanov <vlobanov@...akeasy.net>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] include/linux/slab.h: new KFREE() macro.

--- Vadim Lobanov <vlobanov@...akeasy.net> wrote:

> On Sun, 2007-01-07 at 14:43 -0800, Amit Choudhary wrote:
> > Any strong reason why not? x has some value that does not make sense and can create only
> problems.
> > And as I explained, it can result in longer code too. So, why keep this value around. Why not
> > re-initialize it to NULL.
> 
> Because it looks really STRANGE(tm). Consider the following function,
> which is essentially what you're proposing in macro-ized form:
> 	void foobar(void)
> 	{
> 		void *ptr;
> 
> 		ptr = kmalloc(...);
> 		// actual work here
> 		kfree(ptr);
> 		ptr = NULL;
> 	}

That's where KFREE(ptr) comes in so that the code doesn't look ugly and still the purpose is
achieved.

"I still do not know of a single good reason as to why we should not do this."

And if all programmers did the right thing always then why do we have all the debugging options in
the first place.

> Reading code like that makes me say "wtf?", simply because 'ptr' is not
> used thereafter,

Really? Then why do we have all the debugging options to catch re-use of the memory that has been
freed. So many debugging options has been implemented, so much effort has gone into them, partly
because programmers sometimes miss correct programming.

> so setting it to NULL is both pointless and confusing
> (it looks out-of-place, and therefore makes me wonder if there's
> something stupidly tricky going on).
> 
> Also, arguably, your demonstration of why the lack of the proposed
> KFREE() macro results in longer code is invalid. Whereas you wrote:
> 	pointer *arr_x[size_x];
> 	pointer *arr_y[size_y];
> 	pointer *arr_z[size_z];
> That really should have been:
> 	pointer *arr[size_x + size_y + size_z];
> or:
> 	pointer **arr[3] = { arr_x, arr_y, arr_z };
> In which case, the you only need one path in the function to handle
> allocation failures, rather than the three that you were arguing for.
> 

I do not know what you are talking about here. You are saying that a function does not need three
different arrays with different names. How can you say that? How do you know what is the
requirement?

-Amit

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/