Ultrix CC bug?

[News system owner ID]

< ....  In C, parameters to (non-prototyped) functions are widened,
< so that `char' and `short' both become `int'.  On a VAX, when one writes
< 
< 	f(x) char x; { char *p = &x; ... }	
< 
< one gets a pun from the actual parameter (which has been `sent in' on
< the stack as an int) to the desired parameter (a char), while on the
< 680x0, one gets a conversion.  ...
< -- 
< In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
< Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris

I would add one further though to this: avoid expressions like the
above f(x) like the plague.  This will, regretably, work on Vax,
68xxx, etc. "normal processors", but will fail miserably on machines
like a Pyramid where the first N arguments to a function are placed in
a register window.  Just go and try to take the address of a register
:-(.

I found out about this horridness the hard way, by dealing with the
memory allocator of csh, which assumes that it can correctly tell what
was really allocated and what wasn't, so the user can blithly xfree()
anything (even static strings), and xfree() can catch the "wrong
ones".  Ugh, feh, ick!

Every once in a while, I get the urge to hack gcc to produce correct,
but uncommon, code (like a pointer to a structure points to the _end_
of it, and all other elements are negitive offsets), just to make code
fail.

Don't take the address of a paramater, please.

		-- Paul Placeway
		   <pplaceway at bbn.com>, <paul at cis.ohio-state.edu>