Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-unix!hplabs!cae780!leadsv!scampi!ramin
From: ramin@scampi.UUCP
Newsgroups: comp.arch
Subject: Re: Aliasing, etc. in C
Message-ID: <171@scampi.UUCP>
Date: Thu, 5-Feb-87 18:03:50 EST
Article-I.D.: scampi.171
Posted: Thu Feb  5 18:03:50 1987
Date-Received: Sun, 8-Feb-87 00:44:18 EST
References: <7803@decwrl.DEC.COM> <5230@mimsy.UUCP>
Organization: Systems Control, Palo Alto, CA
Lines: 76
Summary: some other perhaps enlightening info

In article <5230@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> Guy hardly needs defending, but it may sound better coming from two
> people:
> 
> 	/* this code is not portable */
> 	int a,b, *ptr;
> 
> 	ptr = &a;
> 	ptr++;
> 	/* ptr now points to b */
> 
I agree entirely...
In fact, I conducted a quick experiment on a Sun-3 system which resulted
in vastly different results depending on the location of the "int a,b, *ptr"
line:

	long	a,b,*ptr;	/* note: it's static */
	main()
	{
		a = 1; b = 2;
		ptr = &a;
		ptr++;
		*ptr = 3;
		printf("%08.8X %08.8X %08.8X\n",&a,&b,ptr);
		printf("%d %d %d\n",a,b,*ptr);
	}

which resulted in:

00020DBC 00020DC0 00020DC0
1 3 3

and also...

	main()
	{
	long	a,b,*ptr;	/* note: it's NOT static */
	
		a = 1; b = 2;
		ptr = &a;
		ptr++;
		*ptr = 3;
		printf("%08.8X %08.8X %08.8X\n",&a,&b,ptr);
		printf("%d %d %d\n",a,b,*ptr);
	}

which gave:

0EFFFE98 0EFFFE94 0EFFFE9C
1 2 3

Now obviously the second program is a *VERY* problematic one considering
the compiler put a and b on the stack in the reverse order.
As far as I'm concerned both are severely brain-damaged ways of coding.

But the original topic was slanted towards varargs (i.e.
AFTER having called something and the gripe against making assumptions
about doing the above to a call frame) and it got somewhat sidetracked
to discussions of proper C-coding. A utility supplied with a compiler
should be able to to make certain assumption about how the compiler
and the machine it is targeted at pass parameters back and forth.

For the mortals using the compiler to make such an assumption and maintain
portability is folly...

ramin

-- 

(insert-file ".disclaimers")

ramin firoozye'			{ihnp4,lll-lcc,hoptoad}!scampi!ramin
systems control inc.		(415) 494-1165 x-1777
1801 page mill road
palo alto, ca  94304
*** Wars are not fought to decide who is right... Only who is left... ***