[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0610062211220.30417@yvahk01.tjqt.qr>
Date: Fri, 6 Oct 2006 22:18:57 +0200 (MEST)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Muli Ben-Yehuda <muli@...ibm.com>
cc: "Moore, Robert" <robert.moore@...el.com>,
Andrew Morton <akpm@...l.org>, Len Brown <lenb@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ACPI List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH] Cast removal
>> - (void) kmem_cache_destroy(cache);
>> + kmem_cache_destroy(cache);
>>
>> I believe that the point of the (void) is to prevent lint from
>> squawking, and perhaps some picky ANSI-C compilers. What is the overall
>> Linux policy on this?
>
>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
Adding (void) to the front to line 425 does not get rid of the warning.
So doing so does not seem to be the right way to let others know you
intentionally want to discard the return value. Plus, on top, many
(sometimes older) C books advise to cast to (void) just because
something does not return it.
-`J'
--
Powered by blists - more mailing lists