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

[Jeffrey A Law <law at cygnus dot com>]

  In message <199803241750.MAA00882@caip.rutgers.edu>you write:
  > 	Well, that gets kind of gross.  You then have four cases which
  > you have to intricately ifdef you way around inside the function.  Ie,
  > the cross product of __STDC__ (yes/no) and HAVE_VPRINTF (yes/no).  If
  > we go this route, I'd like to come of with a generalized workable
  > solution we can use across the board.  (See below.)
Yup.  it's a pain.

  > 	The gcc source is inconsistent in this regard.  Eg, files like
  > cccp.c/cexp.c handle missing vfprintf by sucking arguments out using
  > va_arg() and then calling fprintf.
That would be a fine solution too.  In fact it's better than pretending 
everything is an int like we do now.

  > 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