Pyramid's "non-standard" C compiler

Sir Hoyt hoyt at polyslo.CalPoly.EDU
Wed Aug 2 01:29:07 AEST 1989


In article <235 at massey.ac.nz> K.Spagnolo at massey.ac.nz (Ken Spagnolo) writes:
>I refer to the fact that in Pyramid C, given 'struct x x;', a call to
>function y() like 'y(x);' will pass to y() the entire structure x, rather
>that just a pointer to x, as is the case with all other C compilers I know
>about.  

	Um, if memory servers me right, there is nothing in the
	C language the specifies how structures are to be passed.
	It only states that you can pass them.  Pyramid is not the only
	machine that does this, the IBM RT will also pass the entire
	struct at times.


>This causes a fair amount of havoc when trying to bring up pd
>software that hasn't been 'Pyramidized'.  We have gone thru several painful
>experiences with things like atalkad where we had to use lint, or some
>less scientific method, to figure out where to change occurences of y(x)
>to y(&x), etc.

	Any code that breaks because of this is wrong.  I have moved
	code between Pyramids, Suns, and Sequents with out any
	problems what so ever.  From what you say, it seems to me
	that the people think:

		int y( x )
		struct yy *x;
		{

		}

	Should be called like:

		struct yy c;
		.
		.
		y( c );
		.
		.

	This is wrong, period.  the function 'y' should be declared
	like:

		struct y( x )
		struct yy x;
		{

		}


>What do other Pyramid users do about this?  Has anyone come up with an
>easy method of discovering where changes need to be made, or written a
>program to do so?  Would it not be a simple matter to have a cc option
>that turned off this feature?  Might there be an undocumented one already?
>All responses are appreciated!

	What do we do? We bitch about the rotten code people write.
	Not all of the world is a Vax..... ( as the saying goes )


-- 
John H. Pochmara				 A career is great, 
UUCP: {csun,voder,trwind}!polyslo!hoyt		 But you can't run your 
Internet: hoyt at polyslo.CalPoly.EDU		 fingers through its hair
							-Graffiti 4/13/83



More information about the Comp.sys.pyramid mailing list