Path: utzoo!attcan!uunet!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Variable argument lists.
Message-ID: <1109@mcgill-vision.UUCP>
Date: 18 May 88 07:00:27 GMT
References: <14139@brl-adm.ARPA> <11435@mimsy.UUCP> <5266@bloom-beacon.MIT.EDU> <11453@mimsy.UUCP>
Organization: McGill University, Montreal
Lines: 47
Posted: Wed May 18 03:00:27 1988

In article <11453@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
>> In article <14139@brl-adm.ARPA> bates%falcon.dnet%fermat@bru.mayo.edu (Cary Bates) wrote:
>>> In VAX C [by which I presume he means some version of VMS C] [...]
> In article <5266@bloom-beacon.MIT.EDU> peter@athena.mit.edu (Peter J Desnoyers) answers this with:
>> As pointed out, it is VAXC, not VMS C.
> Calling something `VAX C' or `VAX PASCAL' or `VAX FORTRAN' is a game
> I refuse to play.  DEC invented it for the `VAX means VMS; VMS means
> VAX' campaign.  [Those years] have now been declared over---by Ken
> Olson no less---and I think it is about time this bit of doublespeak
> is smashed utterly.

(Finally, someone else who sees through this bit of propaganda!)  It's
not restricted to DEC and the net, I'm afraid.  Some magazines contain
ads talking about "<feature foo> for your VAX", but on closer reading,
the language they use makes it abundantly clear they really mean
"...for your VMS VAX".  It's soooo tempting to find one that doesn't
*say* VMS anywhere, order the product, and then complain about how it
won't install - we can't even read the distribution!  (cackle :-)

>> The VAX explicitly saves a lot of information on the stack when it
>> makes a subroutine call, and argument list length is one of them.
> But it is not.  The object stored on the stack is a ten bit field
> holding the number of bytes for a `return' instruction to pop.

It's not even that.  It's an eight-bit field containing the number of
longwords to pop.  And it should be noted that (a) there's a version of
the call instruction - callg - that doesn't use the stack for arguments
and (b) it is perfectly possible to use the bsbb/bsbw/jsb instructions
to build a calling sequence that doesn't do the song and dance that
calls/callg do.  (Why does the Berkeley assembler contain no j version
of bsbb?  Anyone know?)

> And this is the problem with va_count(): even if it uses a `hidden
> argument' (something other than the return byte count), it can only
> tell you how many arguments there were.  It cannot tell you their
> types.  In short, it is not general enough for C.

Only because it returns only one value.  There's nothing preventing a
compiler from pushing all sorts of hidden stuff describing the arglist
in detail for the subroutine.  (Nobody would be silly enough to build
such a compiler, except possibly for find-the-bug-I-don't-care-beans-
about-speed use.)

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu