This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for g77/fortran "format not a string literal" warnings
- To: law at cygnus dot com
- Subject: Re: Patch for g77/fortran "format not a string literal" warnings
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Tue, 30 Nov 1999 17:30:01 -0500 (EST)
- Cc: egcs-patches at egcs dot cygnus dot com
> From: Jeffrey A Law <law@cygnus.com>
>
> In message <199911290212.VAA27084@caip.rutgers.edu>you write:
> > > From: Jeffrey A Law <law@cygnus.com>
> > >
> > > > +
> > > > +extern int vasprintf (char **, const char *, va_list) ATTRIBUTE_PRI
> > NTF(2,0
> > > Err, shouldn't we get this from an include file? Like libiberty.h?!?
> >
> > I though about that, but currently we don't guarantee a definition for
> > va_list everywhere libiberty.h is used. We do so in the gcc directory
> > which gets stdarg.h via system.h. But many/most of the files in the
> > libiberty directory itself don't include stdarg.h/varargs.h to get
> > va_list, and thus they fails to compile. Other packages which use
> > libiberty.h (binutils? gdb?) would have the same issue.
>
> Instead of inventing a new way to do this, why not do something
> similar to stdio.h which has the same problem (but isn't allowed to
> include stdarg.h).
>
> Don't we always have a macro which can be used to test for a proper
> va_list (and if one hasn't been provided to provide one). I believe
> that's how every modern stdio works.
>
> Then again, we're not constrained by ANSI/ISO standards and can
> include stdarg.h in libiberty.h.
>
> I can live with either solution.
> jeff
Oh, do you mean testing _VA_LIST or _VA_LIST_? I wasn't aware we
could rely on this for all platforms. If we can, I think that's a
much better solution. Will someone confirm what the standard says is
the actual macro we should rely on?
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions