From: Muli Ben-Yehuda <muli@il.ibm.com>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: "Moore, Robert" <robert.moore@intel.com>,
Andrew Morton <akpm@osdl.org>, Len Brown <lenb@kernel.org>,
"Brown, Len" <len.brown@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] Cast removal
Date: Fri, 6 Oct 2006 22:30:42 +0200 [thread overview]
Message-ID: <20061006203042.GK14186@rhun.haifa.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0610062211220.30417@yvahk01.tjqt.qr>
On Fri, Oct 06, 2006 at 10:18:57PM +0200, Jan Engelhardt wrote:
> >IMHO there's another reason to do this which is much more relevant: it
> >tells the reader that whoever wrote it knows that it returns a value
> >and ignores it on purpose.
>
> And GCC does not care about that, i.e. it still prints foritfy warnings,
> as in:
>
> $ svn co https://svn.sourceforge.net/svnroot/ttyrpld/trunk a && cd a
> $ make user/rpld.o EXT_CFLAGS="-D_FORTIFY_SOURCE=2"
> user/rpld.c:425: warning: ignoring return value of ‘write’, declared
> with attribute warn_unused_result
Sure, if an interface is decalred with warn_unused_result gcc should
warn, even if the caller casts it to void. But in the normal case,
casting the result of the function to void tells the reader that you
know that it returns something, and you don't care.
Cheers,
Muli
next prev parent reply other threads:[~2006-10-06 20:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-05 22:14 [PATCH] Cast removal Moore, Robert
2006-10-05 22:26 ` Andrew Morton
2006-10-06 5:34 ` Jan Engelhardt
2006-10-06 14:35 ` Muli Ben-Yehuda
2006-10-06 20:18 ` Jan Engelhardt
2006-10-06 20:30 ` Muli Ben-Yehuda [this message]
2006-10-06 20:39 ` Arjan van de Ven
-- strict thread matches above, loose matches on Subject: below --
2006-10-05 22:23 Brown, Len
2006-10-05 15:45 Moore, Robert
2006-10-04 21:40 Moore, Robert
2006-10-05 0:28 ` Andrew Morton
2006-09-30 22:28 Jan Engelhardt
2006-10-05 3:56 ` Len Brown
2006-10-05 4:12 ` Andrew Morton
2006-10-05 4:43 ` Len Brown
2006-10-05 5:19 ` Andrew Morton
2006-10-05 8:00 ` Jan Engelhardt
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=20061006203042.GK14186@rhun.haifa.ibm.com \
--to=muli@il.ibm.com \
--cc=akpm@osdl.org \
--cc=jengelh@linux01.gwdg.de \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robert.moore@intel.com \
/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