From: Amit Choudhary <amit2030@yahoo.com>
To: Vadim Lobanov <vlobanov@speakeasy.net>
Cc: Christoph Hellwig <hch@infradead.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] include/linux/slab.h: new KFREE() macro.
Date: Sun, 7 Jan 2007 16:02:00 -0800 (PST) [thread overview]
Message-ID: <261558.33282.qm@web55609.mail.re4.yahoo.com> (raw)
In-Reply-To: <1168212133.2744.17.camel@dsl081-166-245.sea1.dsl.speakeasy.net>
--- Vadim Lobanov <vlobanov@speakeasy.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
next prev parent reply other threads:[~2007-01-08 0:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-07 8:46 Amit Choudhary
2007-01-07 10:24 ` Christoph Hellwig
2007-01-07 22:43 ` Amit Choudhary
2007-01-07 23:22 ` Vadim Lobanov
2007-01-08 0:02 ` Amit Choudhary [this message]
2007-01-08 2:35 ` Vadim Lobanov
2007-01-08 4:09 ` Amit Choudhary
2007-01-08 7:04 ` Vadim Lobanov
2007-01-08 7:29 ` Amit Choudhary
2007-01-08 8:15 ` Vadim Lobanov
2007-01-08 8:47 ` Amit Choudhary
2007-01-08 9:09 ` Al Viro
2007-01-08 7:49 ` Hua Zhong
2007-01-08 8:00 ` Pekka Enberg
2007-01-08 8:31 ` Amit Choudhary
2007-01-08 8:37 ` Al Viro
2007-01-08 8:39 ` Sumit Narayan
2007-01-08 8:44 ` Robert P. J. Day
2007-01-08 8:56 ` Amit Choudhary
2007-01-08 8:45 ` Pekka Enberg
2007-01-08 9:06 ` Amit Choudhary
2007-01-08 9:26 ` Pekka Enberg
2007-01-08 22:43 ` Valdis.Kletnieks
2007-01-09 19:02 ` Amit Choudhary
2007-01-09 19:19 ` Randy Dunlap
2007-01-10 4:57 ` Amit Choudhary
2007-01-09 22:57 ` Valdis.Kletnieks
2007-01-10 0:00 ` Amit Choudhary
2007-01-10 2:43 ` Valdis.Kletnieks
2007-01-08 11:10 ` Jesper Juhl
2007-01-08 8:05 ` Amit Choudhary
2007-01-08 8:12 ` Al Viro
2007-01-08 8:57 ` Hua Zhong
-- strict thread matches above, loose matches on Subject: below --
2007-07-23 17:55 Amit Choudhary
[not found] <7ADs5-25a-11@gated-at.bofh.it>
[not found] ` <7AP02-3l3-13@gated-at.bofh.it>
2007-01-08 18:29 ` Bodo Eggert
2007-01-01 0:17 Amit Choudhary
2007-01-01 3:01 ` Segher Boessenkool
2007-01-01 21:23 ` Pekka Enberg
2007-01-02 9:21 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=261558.33282.qm@web55609.mail.re4.yahoo.com \
--to=amit2030@yahoo.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vlobanov@speakeasy.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®