Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!prls!mips!dce
From: dce@mips.UUCP
Newsgroups: comp.arch
Subject: Re: Aliasing, etc. in C (available no. of registers)
Message-ID: <151@quacky.mips.UUCP>
Date: Mon, 26-Jan-87 11:04:46 EST
Article-I.D.: quacky.151
Posted: Mon Jan 26 11:04:46 1987
Date-Received: Sat, 7-Feb-87 11:03:34 EST
References: <7803@decwrl.DEC.COM>
Reply-To: dce@quacky.UUCP (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 56


In article <7803@decwrl.DEC.COM> brandenberg@star.dec.com (bleakness...desolation...plastic forks...) writes:
>
>[ From sun!gorodish!guy ]
...
>>No program that relies on that [aliasing] is correct C, so no compiler is
>>obliged to make them work.  In fact, the sooner such programs *are*
>>prevented, the better off we'll all be.
>
>Oh?  If this is aberrant coding, you might want to look at your
>varargs.h file whose operation relies on these assumptions; and this is
>in the ANSI proposal.
>
>					- Monty

Hold on. What Guy says is that no compiler is "obliged" to make the
specifically given code work. The ANSI proposal requires that varargs.h
be implemented and that it aid in performing a certain function. It
does not say *how* variable number of arguments has to work.

In the Mips system, where the first 4 parameters to a subroutine are
passed in registers, the compiler actually keys on the word 'va_alist'
in the argument list to force the parameters to be copied onto the
stack. Because of this, you can actually do some very machine-dependent
code. For example, I've found cases where code like:

	error(code, fmt, args)
		int code;
		char *fmt;
		int args;
	{
		...
		_doprnt(fmt, &args, stderr);
		...
	}

was "ported" to our system by simply changing all instances of "args" to
"va_alist". This was done because the person doing the porting looked at
varargs.h and used system-dependent knowledge instead of using what the
definition says. The fact that "it works" doesn't make it legal, since
it doesn't use the "required" va_start() or va_end().

Basically, all the ANSI proposal says is that a conforming system has to
supply:

	a. varargs.h, which may even be effectively empty
	b. the items listed in varargs(3)

It makes no difference to the ANSI proposal whether va_alist is a macro,
a typedef, or a builtin type. It shouldn't matter to the code how the
arguments are stored or how va_arg() is implemented. Don't confuse requirements
for functionality with requirements for architectural conformity.
-- 
			David Elliott

UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!dce, DDD:  	408-720-1700