From: "Joseph D. Wagner" <wagnerjd@prodigy.net>
To: "'Russell King'" <rmk@arm.linux.org.uk>
Cc: "Linux Kernel Development List" <linux-kernel@vger.kernel.org>
Subject: RE: Good Idea (tm): Code Consolidation for Functions and Macros that Access the Process Address Space
Date: Sun, 6 Oct 2002 07:40:44 -0500 [thread overview]
Message-ID: <000801c26d35$9d6ac670$81281c43@joe> (raw)
In-Reply-To: <20021006105008.B27487@flint.arm.linux.org.uk>
>> On Sat, Oct 05, 2002 at 07:58:55PM -0500, Joseph D. Wagner wrote:
>> SUBJECT: Good Idea (tm): Code Consolidation for Functions and Macros
>> that Access the Process Address Space
>>...
>> Remember, if a function call has no place for a returned value to go,
>> nothing bad happens; the returned value is simply ignored/discarded.
> And the compiler warning?
See WHY THIS SHOULD BE CHANGED #3 "Forces better coding structures and
procedures..." Frankly, error controls should have been programmed into
the code anyway. It's just good programming practice.
>> SOLUTION:
> Get rid of the _ret forms. Their use is frowned on today anyway
because
> they hide the real meaning of what the code is trying to do, and
hiding
> the fact that a function can return in the middle of what looks like a
> macro call is _REAL_ _BAD_.
While I respectively disagree with you, I really don't care which set of
functions/macros are eliminated for consolidation purposes. My original
point still stands that maintaining duplicate functions -- well, near
duplicate with the exception of the returned error code -- is a waste of
time, resources, and coding, and for the purpose of simplified
maintenance, one of the sets of duplicate functions/macros should be
eliminated.
Joseph Wagner
next prev parent reply other threads:[~2002-10-06 12:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-06 0:58 Good Idea (tm): Code Consolidation for Functions and Macros that Access the Process Address Space Joseph D. Wagner
2002-10-06 9:50 ` Russell King
2002-10-06 12:40 ` Joseph D. Wagner [this message]
2002-10-06 13:29 ` Russell King
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='000801c26d35$9d6ac670$81281c43@joe' \
--to=wagnerjd@prodigy.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.