Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA
Path: utzoo!utcs!lsuc!pesnta!amd!dual!ucbvax!info-vax
From: info-vax@ucbvax.ARPA
Newsgroups: fa.info-vax
Subject: Re: DEC C (2.0)
Message-ID: <4999@ucbvax.ARPA>
Date: Thu, 21-Feb-85 15:54:16 EST
Article-I.D.: ucbvax.4999
Posted: Thu Feb 21 15:54:16 1985
Date-Received: Fri, 22-Feb-85 14:33:51 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 22

From: Gail Rubin <grubin@bbn-spca>

Your information about the C standard and portability is reasonable
however, the particular application I am concerned with in my message is
one that is explicitly designed for VMS only. On the VAX, I KNOW what the
stack format is and since I don't use doubles as arguments, the number of
longwords IS the number of arguments.

My application is a package of routines, a run-time library of sorts, that
gets sent to customers and they write programs which call the routines.
Since I then have absolutely no control over whether my routines are called
correctly, or what language they are called from and some of the routines
do have optional arguments, I try to check the number of arguments as one
of my validity checks so I can give a more explicit error code back to the
user program instead of an access violation or strange behavior. I follow
calling standard behavior in that I never modify actual arguments;
basically all arguments are passed by reference or descriptor anyway.

In light of this, the behavior of DEC C 2.0 is
unsuitable for my application. I would be more inclined to stick with
the C I have rather than rewrite my routines in Macro.
-- Gail