This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs-980315, gen*.c system.h and fatal() using stdarg/varargs
- To: law at cygnus dot com
- Subject: Re: egcs-980315, gen*.c system.h and fatal() using stdarg/varargs
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Tue, 24 Mar 1998 16:36:53 -0500 (EST)
- Cc: egcs at cygnus dot com, ghazi at caip dot rutgers dot edu
> From: Jeffrey A Law <law@hurl.cygnus.com>
>
> > To me it seems that if vfprintf is
> > missing, it is a dubious proposition to assume varargs.h/va_arg() are
> > present.
> No. There was a time when this was common. As systems have moved to
> ANSI/POSIX compliance this is less of an issue, but we need to handle
> it.
>
> > there any known platforms which fit this description, missing vfprintf
> > but have varargs.h/va_arg()?)
> I believe so, it was certainly the case in the past.
>
> > http://www.cygnus.com/ml/egcs/1998-Feb/1155.html, then this issue goes
> > away except where we have to pass a function pointer (which does come
> > up in the gcc source, but not in gen*.c.) Just a thought.
> >
> > Another thing we can do is put the following in system.h:
> Either would probably be reasonable. I'd probably lean towards
> defining some crude vfprintf in system.h for systems without vfprintf
> support so that we don't have to go change all the sources.
>
> Another thought would be to link with libiberty since it has some
> vfprintf (though I suspect it just calls doprnt).
>
> jeff
Yes I looked at egcs/libiberty/vfprintf.c and you're right, it
just calls _doprnt.
I guess I agree with you that defining vfprintf to something is
better than mucking with the source code a lot. Though one problem
might be on hosts where stage1 cc does macro replacement inside strings.
The string of chars "vfprintf" appears in fix-header.c and c-common.c.
I don't know if this is serious, but they would get replaced with
whatever we define vfprintf to. Probably with negative results. :-)
One solution is to instead define VFPRINTF() but then we'd
have to muck with the source (though less so than if we replaced
fatal() with FATAL() ...) I checked and vfprintf function calls
appear in cccp.c, cexp.c, gcc.c, mips-tfile.c and toplev.c. Not too
bad.
So here is the latest proposal, stick the following in system.h:
#ifdef HAVE_VPRINTF
# define VFPRINTF(stream, format, args) vfprintf(stream, format, args)
#else /* ! HAVE_VPRINTF */
# ifdef HAVE_DOPRNT
# define VFPRINTF(stream, format, args) _doprnt(format, args, stream)
# else /* ! HAVE_DOPRNT */
# define VFPRINTF(stream, format, args) \
do { \
HOST_WIDE_INT a0 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a1 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a2 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a3 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a4 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a5 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a6 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a7 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a7 = va_arg(args, HOST_WIDE_INT); \
HOST_WIDE_INT a9 = va_arg(args, HOST_WIDE_INT); \
fprintf (stream, format, a0, a1, a2, a3, a4, a5, a6, a7, a8, a9); \
} while (0)
# endif /* HAVE_DOPRNT */
#endif /* HAVE_VPRINTF */
and change the function `fatal' in gen*.c as per my original patch
except that instead of calling vfprintf, they call VFPRINTF.
Shall I implement this?
--Kaveh
PS: Is there any way to turn off __attribute__ printf for just one call
to fprintf? The call to fprintf in the VFPRINTF macro above will always
get a bunch of warnings (unless `format' has 10 HOST_WIDE_INTs in it)
but we know this is okay to ignore. Can they be silenced for just that
invocation? If not, its not a big deal since it will only happen to
hosts which have neither vfprintf nor _doprnt.
--
Kaveh R. Ghazi Project Manager / Custom Development
ghazi@caip.rutgers.edu Icon CMT Corp.