andrew@frip.gwd.tek.com (Andrew Klossner) (04/26/88)
[]
"This function used to be called nargs() and it was removed
from PDP-11 UNIX when the PDP-11/70 came out, precisely because
it became clear that programs that relied on it would have
problems when ported to new machines."
Specifically, because it couldn't be implemented in a process with
separate I&D space, because there is no way (short of a system call)
for such a process to look at its own instructions.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/27/88)
It is perhaps also worth pointing out that nargs() didn't really return the number of arguments, just the number of words on the stack used for arguments. As C grew, this became less sensible. I can easily enough imagine a reasonable implementation of C for which requiring that something like nargs() work would force a slower function call interface, which would be a poor trade-off.
dave@lsuc.uucp (David Sherman) (05/03/88)
I thought I really needed nargs() when I moved our CAI applications
from the PDP-11/23 development machine to this Perkin-Elmer 3220
(also running v7) in 1984. Then I started getting advice from
the PE experts on the net, who explained why it couldn't be done
(most notably because the first argument is stored in space that's
used anyway, so 0 and 1 argument can't be distinguished). I took
a look at all the places I used nargs, and found that they weren't
that hard to rewrite portably. Whether you pass an arg count,
use a special flag as first argument (this was for functions called
from signal traps) or terminate the arguments with 0, it can usually
be done.
David Sherman
The Law Society of Upper Canada
--
{ uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave