This is the mail archive of the gcc@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]

Re: egcs-980315, gen*.c system.h and fatal() using stdarg/varargs


 > 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.


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