Variable argument lists.
der Mouse
mouse at mcgill-vision.UUCP
Wed May 18 17:00:27 AEST 1988
In article <11453 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
>> In article <14139 at brl-adm.ARPA> bates%falcon.dnet%fermat at bru.mayo.edu (Cary Bates) wrote:
>>> In VAX C [by which I presume he means some version of VMS C] [...]
> In article <5266 at bloom-beacon.MIT.EDU> peter at 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 at mcgill-vision.uucp
arpa: mouse at larry.mcrcim.mcgill.edu
More information about the Comp.lang.c
mailing list