public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <ian@airs.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: binutils@sourceware.org
Subject: Re: Silence compiler warning on
Date: Wed, 19 Apr 2006 08:22:00 -0000	[thread overview]
Message-ID: <m364l6jc42.fsf@gossamer.airs.com> (raw)
In-Reply-To: <200604190635.k3J6ZoeW019852@elgar.sibelius.xs4all.nl>

Mark Kettenis <mark.kettenis@xs4all.nl> writes:

> > From: Ian Lance Taylor <ian@airs.com>
> > Date: 18 Apr 2006 16:13:59 -0700
> > 
> > Mark Kettenis <mark.kettenis@xs4all.nl> writes:
> > 
> > > Index: ChangeLog
> > > from  Mark Kettenis  <kettenis@jive.nl>
> > > 
> > >         * bfd.c (_bfd_abort): Provide prototype for _exit with
> > >         ATTRIBUTE_NORETURN.
> > 
> > I think something like this should use AC_CHECK_DECLS to avoid a
> > conflict with the system header files.
> 
> I fail to see how that would work.  I'm not trying to add a missing
> prototype; I'm trying to augment a prototype with a noreturn attribute.

You're right, AC_CHECK_DECLS isn't the right thing to use.  What is
needed is some test to make sure that you can compile code with the
declaration that you want to add.

> A conflict with the system header files seems rather unlikely; the
> only variation I could imagine, is that some (pre ISO C) header files
> fail to provide the proper return type.

_exit is not an ISO C function.  System header files are sadly
unreliable when it comes to declaring functions.  If the system header
file happens to declare the function in some incompatible way--say it
uses unsigned int--then you will introduce a build failure.

I think it's safer to use an autoconf test to see whether the
prototype declaration is safe.

We've had unfortunate experiences over the years with attempts to
declare functions which should be declared in system header files.

Ian

  reply	other threads:[~2006-04-19  6:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-18  9:40 Mark Kettenis
2006-04-18 23:50 ` Ian Lance Taylor
2006-04-19  7:44   ` Mark Kettenis
2006-04-19  8:22     ` Ian Lance Taylor [this message]
2006-05-04 18:39 ` Daniel Jacobowitz
2006-05-05 12:20   ` Mark Kettenis
2006-05-05 13:07     ` Daniel Jacobowitz

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=m364l6jc42.fsf@gossamer.airs.com \
    --to=ian@airs.com \
    --cc=binutils@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /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).