Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!princeton!allegra!alice!bs
From: bs@alice.UucP (Bjarne Stroustrup)
Newsgroups: net.lang.c++
Subject: looking for help porting C++
Message-ID: <5809@alice.uUCp>
Date: Thu, 17-Jul-86 21:35:01 EDT
Article-I.D.: alice.5809
Posted: Thu Jul 17 21:35:01 1986
Date-Received: Sat, 19-Jul-86 00:46:44 EDT
Organization: Bell Labs, Murray Hill
Lines: 29

> From: michael@python.UUCP (M. Cain)
> Organization: Bell Communications Research
>
> I'm trying to port C++ to a Hewlett-Packard 550 running
> HPUX.  I was able to make cfront from the ..c files in
> the distribution.  However, cfront complains that "this
> c does not support varargs" when compiling some parts of
> the library and the C++ source for cfront.  HPUX *does*
> support varargs -- but the 550 runs its stack "backwards"
> from the way its done on a VAX.
> ...
> Grepping the C++ source for cfront and the distributed
> include files, I found that none of them reference varargs.h.
> This seems to imply that the code hardwires assumptions about
> the stack, rather than using the stuff in varargs.h.

You are right. Cfront does those assumptions hardwired. The snag is
that when I wrote it I didn't have a C++ varargs and I somehow never
got around to rewriting that part of cfront. Sorry.

> Questions:  Has anyone else had this problem in doing a port?
> Does anyone have any suggestions for fixing the problem?

Yes (are you there Chris?). Actually someone just solved that exact
problem for a Data General machine, but I don't have the code. The
assumptions are locallized to the function error() in error.c. Error()
does a printf-style passing of error message format strings. Fix the way
it gets at its arguments and cfront will run. The same problem occurs
in the function form() in file out.c in the stream library.