Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site gitpyr.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!gitpyr!robert
From: robert@gitpyr.UUCP (Robert Viduya)
Newsgroups: net.lang.c
Subject: gripe: variable arg lists
Message-ID: <348@gitpyr.UUCP>
Date: Wed, 14-Nov-84 08:52:12 EST
Article-I.D.: gitpyr.348
Posted: Wed Nov 14 08:52:12 1984
Date-Received: Thu, 15-Nov-84 04:01:23 EST
Distribution: net
Organization: Georgia Tech, Atlanta
Lines: 68

[]

This has probably been mentioned before, but I'd  like  to  present  a  new
aspect of the old problem of variable arguments.

About a day ago, a program  arrived  at  our  site  via  net.sources.   The
program  was a wargame simulator known as 'ogre'.  I pulled the program off
and compiled and attempted to run it.  The program repeatedly died  in  two
routines:  display()  and display_xy().  For the sake of brevity, and since
the problems in both routines were identical, I'll only show display():

display(line, format, args)
int line;
char *format;
int args;
{

    movecur(line, 0);
    eeol();
    _doprnt(format, &args, stdout);

}

The following are examples of how the author called display():

        display(16, "%s infantry (%d/%d D%d M%d)", action,
            unit[i].attack, unit[i].range,
            unit[i].defend, unit[i].moves_left);

        display(16, "left to place: %d armor, %d infantry%s",
            armor_points, infantry_points,
            (cp_set) ? "." : ", CP");

Note the author's unconventional use of  _doprnt().   The  program's  exact
point of death was in _vaarg().

Obviously, the author  expects  function  parameters  to  be  passed  as  a
sequential  list  of words starting at some memory address.  Well, our site
is running a Pyramid 90x, a RISC machine.  The architecture of the  machine
makes  it  more  efficient to pass parameters in registers, due to the it's
abundance of them (at any moment, a function has access to 64 registers: 16
global  (general), 16 local, 16 parameter, and 16 temporary).  The author's
assumption about memory parameter lists wasn't valid and subsequently,  the
program died trying to access the arguments.

I'm not defending the author  of  the  program.   He  shouldn't  have  used
_doprnt() as it is an internal function of the standard C library and there
isn't any guarantee that it will be in some future revision of  the  OpSys.
However,  if C had a _s_t_a_n_d_a_r_d method of supporting variable-length argument
lists, he probably wouldn't have resorted to using _doprnt().

Anyway, put  this  message  down  as  another  reason  to  standardize  the
language,  especially  the intentionally vague areas like variable-argument
lists.

One more thing:  I've already fixed the  program  to  printf()  instead  of
_doprnt().  Don't bother sending me instructions on how to do so.


					robert
-- 
Robert Viduya
Office of Computing Services
Georgia Institute of Technology, Atlanta GA 30332
Phone:  (404) 894-4669

...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
...!{rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert