public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
To: meissner@cygnus.com
Cc: amylaar@cygnus.co.uk, gcc@gcc.gnu.org, gdr@codesourcery.com
Subject: Re: Silently checking whether diagnostics would occur
Date: Thu, 14 Sep 2000 08:31:00 -0000	[thread overview]
Message-ID: <200009141530.LAA09532@caip.rutgers.edu> (raw)

 > From: Michael Meissner <meissner@cygnus.com>
 > 
 > Rather than returning an error value, you could have the parameter be
 > an int pointer, and if the pointer is NULL, otherwise set the pointer
 > to non-zero and return.  Another way to write the function is to pass
 > a function that writes the error messages, and for the case you don't
 > want the error messages, have it record in a static about being called
 > and return, and change the other callers to pass error or what have
 > you for the function.

One nit with passing in a function is that attribute printf doesn't
work on function pointers IIRC, so all the calls to the warning
function ptr would lose format checks.  (Though I suppose that could
be fixed.)  Sigh, that would have been cleaner since I could do
"#pragma poison warning" to make sure the function pointer parameter
was always used in preference to `warning'.


I'll look into passing in an int*, then I guess all calls to warning()
would instead be:

 > if (foo)
 >   {*foo = 1; return;}
 > else
 >   warning ("blah blah", arg1, arg2);

Although I appreciate now the reasons against using a global var, I
also see maintenance problems down the road ensuring that one always
uses the above idiom when adding new format checks.

Any ideas on making it more automatic and less dependent on good
behavior?  Since `warning' is a varargs function, for portability
reasons I can't make the above snippet a macro.

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions

             reply	other threads:[~2000-09-14  8:31 UTC|newest]

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

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=200009141530.LAA09532@caip.rutgers.edu \
    --to=ghazi@caip.rutgers.edu \
    --cc=amylaar@cygnus.co.uk \
    --cc=gcc@gcc.gnu.org \
    --cc=gdr@codesourcery.com \
    --cc=meissner@cygnus.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).