public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Meissner <meissner@cygnus.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: gdr@codesourcery.com, gcc@gcc.gnu.org
Subject: Re: Silently checking whether diagnostics would occur
Date: Wed, 13 Sep 2000 13:51:00 -0000	[thread overview]
Message-ID: <20000913165105.03587@cse.cygnus.com> (raw)
In-Reply-To: <200009131550.LAA13911@caip.rutgers.edu>

On Wed, Sep 13, 2000 at 11:50:02AM -0400, Kaveh R. Ghazi wrote:
> Hi Gabriel,
> 
> While writing a __builtin_printf expander, I found that it would be
> useful to be able to call the printf format checking routines silently
> from builtins.c to see if the printf call being expanded passed format
> checks before I try to optimize it.  (This needs to happen regardless
> of, and independent of, whether the user specifies -Wformat.)  The
> current format checking routines are setup to emit warnings at random
> points, not to return a handy status code.  (See check_format_info in
> c-common.c.)
> 
> So rather than do a complete restructuring of the format checking
> function, I though it would be much easier and cleaner to be able to
> call the checks conceptually like this:
> 
>  > check_diagnostics_silently = 1;  /* new global vars */
>  > diagnostic_occurred = 0;
>  > 
>  > <do something which might warn>
>  > 
>  > if (diagnostic_occurred) <react>
>  > check_diagnostics_silently = 0;
> 
> and modify diagnostic.c:count_error to do this before anything else:
> 
>  >   if (check_diagnostics_silently)
>  >     {
>  >       diagnostic_occurred = 1;
>  >       return 0;
>  >     }

I really, really do not like adding global variables for this purpose (yes, I'm
probably guily of just such behavior myself).  I would rather the checking be
abstracted into a function with an argument that says whether to issue the
warning or not, and a return value that indicates whether an error would have
occurred.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

  reply	other threads:[~2000-09-13 13:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-13  8:50 Kaveh R. Ghazi
2000-09-13 13:51 ` Michael Meissner [this message]
2000-09-13 16:37 ` Joern Rennecke
2000-09-13 14:33 Kaveh R. Ghazi
2000-09-13 20:37 ` Michael Meissner
2000-09-13 17:38 Mike Stump
2000-09-14  7:43 Kaveh R. Ghazi
2000-09-14  8:31 Kaveh R. Ghazi
2000-09-14  8:42 ` Michael Meissner
2000-09-14 10:47 ` Joseph S. Myers
2000-09-14 12:37 ` Joern Rennecke
2000-09-15 11:12 Kaveh R. Ghazi
2000-09-15 11:25 Kaveh R. Ghazi

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=20000913165105.03587@cse.cygnus.com \
    --to=meissner@cygnus.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdr@codesourcery.com \
    --cc=ghazi@caip.rutgers.edu \
    /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).