public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: "David E. Weekly" <dweekly@legato.com>
Cc: <gcc@gnu.org>
Subject: Re: Patch to Add -Wunused-returns
Date: Fri, 07 Dec 2001 04:15:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.33.0112071122590.7144-100000@kern.srcf.societies.cam.ac.uk> (raw)
In-Reply-To: <0c4f01c17edd$5bbbefc0$5c044589@legato.com>

On Thu, 6 Dec 2001, David E. Weekly wrote:

> Thanks for your wide response (generally along the lines of "okay, if you
> want it - do it!"). I've resurrected Gray Watson's patch
> (http://256.com/gray/) and 95% of the credit of this patch belongs to him.

A current copyright assignment or disclaimer from him will probably be
needed, then.  (The old copy of copyright.list I have only shows

CCCP    Gray Watson     1992-04-21
Disclaims changes to cccp.

CCCP    Antaire Corporation     1992-04-21
Disclaims changes made by Gray Watson to cccp.
info@antaire.com

.)

> (I obtained his permission to resurrect this patch.) I basically just
> slapped his code in there my way and gave it a quick check. Seems to work on
> some simple test cases just fine.

Testcases need to be included in a form suitable for the testsuite (see
existing tests for warnings in gcc.dg).  They should probably test at
least:

* Void value ignored, no warning.
* Non-void value ignored, warning.
* Non-void value cast to void, no warning.

> Incidentally, when running my diff it became clear that some files are in
> CVS that oughtn't be -- i.e., are autogenerated! Here they are:
> 
>     fastjar/Makefile.in (made from fastjar/Makefile.am)
>     fastjar/configure   (made from configure.in)
> 
> Needless to say, having these auto-generated files in CVS makes diffing
> annoying. =)

You should use contrib/gcc_update --touch to avoid files getting
spuriously rebuilt.  These files need to be in CVS for just running
configure and building the compiler from CVS to work - and there are
strong restrictions on the suitable versions of autoconf.

> There were also numerous warnings when compiling GCC from GCC 2.96 and XGCC
> itself. Is this okay, or is the hope to someday have a smooth, clean build?

You should make sure your changes don't add any new warnings.

> +    warning("return value from function ignored");

Space before open parenthesis.

> +@item -Wunused-returns @r{(C only)}
> +@opindex Wunused-returns
> +Warn whenever the result of a non-void function is implicitly cast away.
> +It is not included in the above, because it requires @code{void} casting
> +returns of all sorts of regular functions, like @code{close} and
> +@code{printf}, whose return value you usually don't care about. This makes
> +GCC more like Lint.

The position you've put this in the file implies it's included in -Wall,
since -Wall below says that all the above -W options are included.  It
should go somewhere below -W in the file.

Please also update trouble.texi so that it says, this is why we don't warn
by default but we have this option if you do want these warnings.  
(Similar to how below it says to use -pedantic-errors to make constraint
violations into errors rather than warnings.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

      parent reply	other threads:[~2001-12-07 11:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-06 22:03 David E. Weekly
2001-12-06 22:14 ` Fergus Henderson
2001-12-06 23:32   ` David E. Weekly
2001-12-07  2:03 ` Neil Booth
2001-12-07  4:15 ` Joseph S. Myers [this message]

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=Pine.LNX.4.33.0112071122590.7144-100000@kern.srcf.societies.cam.ac.uk \
    --to=jsm28@cam.ac.uk \
    --cc=dweekly@legato.com \
    --cc=gcc@gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).