This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix bootstrap on non-C99 systems


> I actually don't have a good handle on when declarations should go
> into libiberty.h.  We currently declare a few functions which are
> provided by libiberty when the system does not provide them, such as
> basename, gettimeofday, and the afore-mentioned asprintf and
> vasprintf.  But libiberty provides a lot of functions which are not
> declared in libiberty.h.  Should they all be declared there?  Should
> they be declared in a different header file?  Should that header
> file be automatically generated in the object directory?

I always thought it would make sense for libiberty to generate an
include file that provided all the HAVE_s and HAVE_DECL_s it needed,
but getting everyone to use it would be tricky, since it would have to
live in a directory not normally searched for includes.  If we can do
that, we can tailor libiberty.h to use them to provide declarations
only when appropriate, and then we can be more comprehensive.

Another alternative is for libiberty to export an m4 file for other
autoconfs to include.

So far, the theory has been that we include prototypes for
libiberty-specific functions (like xmalloc) but not functions which
are normally part of the OS but missing on a few systems (like bcopy)
as the pain of conflicting prototypes was way too high to warrant the
slight margin of safety by including them.

With the advent of C++ compilations we'll have to rethink all that.

We should at least be able to get away with not prototyping anything
that ISO C requires, as a C++ compiler wouldn't (shouldn't?) ever need
them in libiberty.h anyway.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]