#define vfprintf

Jeffrey A Law law@cygnus.com
Wed Apr 15 02:29:00 GMT 1998

  In message < 199804131434.KAA04083@caip.rutgers.edu >you write:
  > 	Sorry I didn't get back to you sooner, I was unavailable last
  > week.
It's OK, I probably couldn't have reviewed it then anyway..

  > 	Since I hadn't introduced any new vfprintf code yet, I wasn't
  > sure what you meant until I bootstrapped the latest snapshot on hpux. 
  > But now I see what you mean.  The hpux compiler chokes on my recent
  > patch to cccp.c and cexp.y in which I moved the following existing code
  > higher up in those files:
Ah, I should have tried to be clearer about how we got into this
situation.  I just assumed that when I mentioned it you'd go "oh,
yea, silly mistake..."

[ ... ]
  > 	None of the above code is new, just its position in the file
  > changed.  The reason I did this is because certain other cc's have the
  > restriction that stdarg.h/varargs.h must appear before stdio.h.
  > However, this causes the conflict on hpux (probably any KNR stage1 cc)
  > between the macro and the prototype.

  > 	This problem will go away when I submit patches to integrate
  > vfprintf.c, because the vfprintf() macro in the above code won't be
  > needed then.  But I won't be done with that very soon, due to my own
  > time constraints.
Any rough estimate?  Weeks? months?

  > 	If we need a stopgap measure, the following patch will do the
  > trick.  Let me know if you want me to install it or wait until
  > vfprintf.c and the associated autoconf hackery is ready. 
Unless the time frame for vfprintf is pretty small (week or so)
then I think we ought to go ahead and put the stopgap in.


More information about the Gcc mailing list