Path: utzoo!utgpu!water!watmath!clyde!rutgers!mcnc!thorin!phi.cs.unc.edu!leech
From: leech@phi.cs.unc.edu (Jonathan Leech)
Newsgroups: comp.lang.c++
Subject: varargs and C++
Message-ID: <969@thorin.cs.unc.edu>
Date: 31 Jan 88 03:52:09 GMT
Sender: news@thorin.cs.unc.edu
Reply-To: leech@phi.cs.unc.edu (Jonathan Leech)
Organization: University Of North Carolina, Chapel Hill
Lines: 36
Expires:
References:
Sender:
Followup-To:
Keywords:


    After porting C++ 1.2.1 to our new Sun-4 tonight, I have come to
the conclusion that there is no way to write C++ code using
<varargs.h> in a portable fashion at this time. Part of the SPARC
<varargs.h> looks like this:

#if defined(sparc)
# define va_alist __builtin_va_alist
#endif
# define va_dcl int va_alist;
# define va_start(list) list = (char *) &va_alist
# define va_end(list)
# define va_arg(list,mode) ((mode *)(list += sizeof(mode)))[-1]

    A little hacking proves conclusively what this suggests: that the
compiler recognizes the '__builtin_va_alist' and inserts magic,
presumably to move parameters passed in registers onto the stack.

    Unfortunately, cfront turns the name into '_au0___builtin_va_alist'
and this mechanism is defeated. Thus without hacking cfront itself to
not prefix names like this, straightforward use of varargs will not
work on a Sun 4.

    This is a problem since the libC form() routine requires varargs.
My workaround is to postprocess lib/mk/out..c and restore the
original name.

    I suspect that this whole business with builtins is going to get
more and more annoying as ANSI-compliant C compilers which actually
use builtins extensively start showing up; hopefully AT&T is already
thinking about solutions.

    Jon Leech (leech@cs.unc.edu)    __@/
    ``After all, the best part of a holiday is perhaps not so much to be
      resting yourself as to see all the other fellows busy working.''
	- Kenneth Grahame, _The Wind in the Willows_