From: Michael Tokarev <mjt@tls.msk.ru>
To: linux-kernel@vger.kernel.org
Subject: functions returning 0 on success [was: [PATCH] Fix a memory leak in the i386 setup code]
Date: Tue, 11 Jul 2006 02:45:39 +0400 [thread overview]
Message-ID: <44B2D893.9050209@tls.msk.ru> (raw)
In-Reply-To: <20060710221308.5351.78741.stgit@localhost.localdomain>
Catalin Marinas wrote:
> From: Catalin Marinas <catalin.marinas@gmail.com>
[]
> - request_resource(&iomem_resource, res);
> + if (request_resource(&iomem_resource, res)) {
> + kfree(res);
...
Just a small nitpick, or, rather, a question.
Quite alot of functions return 0 on success, or !=0 on failure.
There are other functions, which, say, return NULL on failure.
Or when 0 is valid result, something <0 is returned.. etc.
Without looking at the function description or code, it's
impossible to say wich of the above it is. But.
When reading that kind of code as the quoted patch adds,
I for one always think it's somehow incorrect or backwards.
When used like that, request_resource() seems like a boolean,
and the whole thing becomes:
if (do_something_successeful())
fail();
Ofcourse, later you understand that do_something() returns 0
on failure, and the code is correct. But the first impression
(again, for me anyway) is that it's wrong.
In such cases when a routine returns 0 on error, I usually write
it this way:
if (request_resource() != 0)
fail()
This way it becomes obvious what does it do, and compiler
generates EXACTLY the same instructions.
Yes it's redundrand, that "!= 0" tail. But it makes the
whole stuff readable without a need to re-think what does it
return, and, which is especially important, logically correct
when reading.
Alternatively, it can be named something like
request_resource_failed()
instead of just request_resource(). Compare:
if (request_resource(..))
fail();
(current). And
if (request_resource_failed())
fail();
The latter seems more logical... ;)
But that "!= 0" tail achieves almost the same effect.
Yet again, from my point of view anyway... ;)
Thanks.
/mjt
next prev parent reply other threads:[~2006-07-10 22:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-10 22:13 [PATCH] Fix a memory leak in the i386 setup code Catalin Marinas
2006-07-10 22:25 ` Rafael J. Wysocki
2006-07-11 7:47 ` Catalin Marinas
2006-07-11 8:26 ` Rafael J. Wysocki
2006-07-10 22:45 ` Michael Tokarev [this message]
2006-07-10 22:49 ` functions returning 0 on success [was: [PATCH] Fix a memory leak in the i386 setup code] Michael Tokarev
2006-07-15 17:33 ` Dmitry Torokhov
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=44B2D893.9050209@tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-kernel@vger.kernel.org \
/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