decot@cwruecmp.UUCP (Dave Decot) (11/02/83)
I have used the method described (passing lots of int parameters) on both
a PDP/11-45 and a PDP/11-70 with success. Since a long parameter takes
stack space for two ints on these machines, one might think one could encounter
problems. But since the "code" I have advocated calls {f,}printf() with
the same size parameters as err() thinks it has, those parameters are stacked
just as they were by the function that called err(). As long as your machine
consistently stacks parameters, the fragment in question will operate
correctly.
Dave Decot
decvax!cwruecmp!decotmikee@tektronix.UUCP (Mike Edmonds) (11/09/83)
I have seen some advocate using the following code:
foo(fmt,arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9)
char *fmt;
int arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9;
{
/* code, of course */
}
This will work fine on a vax. But I ran into trouble with code like
this when porting dump to an 11/45 and 11/70. If one of your arguments
is a long, as in "foo("d is %ld\n", (long)d)" then you can run into
problems, because of course a long will take *two* of those "int"
spots you reserved. Which makes any arguments following a long all
pretty darn useless, unless you have a pretty specific routine that
knows the 4th argument will always be a long.
It will also confuse you when this happens to be part of your
error detection routine and you rely on accurate output for
debugging!
Rick Lindsley
richl@tektronix
...!tektronix!richl