[fa.info-vax] DEC C compiler

info-vax (06/15/82)

>From reno@DTI-VMS Tue Jun 15 07:35:02 1982
Clearing up two misconceptions:
	1. The DEC C compiler DOES allow two different structures to
have members with the same names, at different offsets (or at the same
offset if you want).
	2. It also allows full passing and returning of structures. To handle
functions returning structures, the calling procedure passes as an extra
argument the address of an area where the called procedure fills in the
structure to be returned.
			- jr

info-vax (06/15/82)

>From reno@DTI-VMS Tue Jun 15 11:29:24 1982
Apparently, the compiler supports both free-floating members and unique
members. If the member name appears at the same offset every time it is 
declared, it is allowed to be used with any structure, even those in
which it is not declared. If it appears at different places in two different
structures, the two instances are unique and the member may not be used
with any other (third) structure.
	There is a switch that will make it complain about nonportable
constructs such as passing and returning structures. 
	Dec has published a handbook on the compiler, titled 'Programming
in VAX-11 C' (order number AA-L370A-TE from DEC). I suggest that anyone
who is curious obtain a copy of this (i assume dec will let you buy it
without the compiler, and that it isn't too expensive) rather than our
getting into lengthy discussions in info-vax.
			- jr

info-vax (06/15/82)

>From dan@BBN-UNIX Tue Jun 15 13:52:10 1982
1. Re structure members: is there a way to obtain the "traditional"
behavior (free-floating structure members useful with any structure)?
Not that I would ever want it, but there's enough software that assumes
it that I would expect portability problems if it were not available
as an option.

2. Re returning structures: this implementation implies some constraints
that the traditional implementation lacks. First, the caller must declare
the routine as returning a structure even if the caller doesn't use
the return value. This is perfectly reasonable, but again it means
a potential portability problem. I assume that if I declare a routine
as returning a structure, and call it without using that return value,
the compiler will still provide the extra address. More important, where
is that "extra argument"? It better not be the last argument, since that
would prohibit functions which return structures from taking a variable
number of arguments.

info-vax@ucbvax.ARPA (02/18/85)

From: Rudy.Nedved@CMU-CS-A.ARPA

Unless I am mistaken, the DEC VAX-11 C compiler generates code for
any function argument that you try to get an address of. The result is
instead of getting the address of the actual stack argument, you get
a copy. This "feature" prevents the porting of programs that have
routines that use variable number of arguments like printf...

Is there a way I can turn off this overly protective stack argument
copying?? 

-Rudy

info-vax@ucbvax.ARPA (02/19/85)

From: sasaki@harvard.ARPA (Marty Sasaki)

You are mistaken. The DEC VAX-11 C compiler puts the arguments on the
stack in the same way. There is even a warning about double arguments,
they violate the VAX calling conventions.

You can do all of the variable number of arguments goodies. You can
do most everything that you can do on BSD.

		Marty Sasaki
		Harvard University Science Center

info-vax@ucbvax.ARPA (02/19/85)

From: ihnp4!houxm!link!piggy!dlm@BERKELEY

You are mistaken.

Taking the address of a function argument references the real argument.
I also don't know of a version of the compiler that ever did what you
suggest.

Daryl Monge
AT&T Bell Labs Holmdel, NJ

...!ihnp4!piggy!dlm

info-vax@ucbvax.ARPA (02/19/85)

From: Rudy.Nedved@CMU-CS-A.ARPA

Marty,

Are you sure we are talking about the same C compiler. I tam talking
about the one that you can do
	CC /MACHINE /LIST=FOO.LIS FOO.C
and you get a listing.

In that listing, all of the routines that do &stackarg get code
generated after the stack set up for locals and before the execution
to copy the stackarg into a routine local.

Maybe we are arguing over different versions? I have about 10 routines
that do this and they all act this way. I had to right a disgusiting
macro-32 hack to chase up the stack (using the old saved AP) to get the
Nth arguent to get the address.

I must agree with Mr Firth that it should be all or none. Given that
I am not a language wiz but a system wiz...I defer to his belief since
he is one of the Tartan Labs folks...and they are in the compiler
business.

-Rudy

info-vax@ucbvax.ARPA (02/19/85)

From: sasaki@harvard.ARPA (Marty Sasaki)

Maybe I'm confused. What is it exactly that you are trying to do?

We are talking about the same compiler.

		Marty

info-vax@ucbvax.ARPA (02/20/85)

From: Rudy.Nedved@CMU-CS-A.ARPA

We have X2.0 DEC C compiler....not eunice compiler.

The compiler will take the following program:
	foo(arg)
	{
	    int *p;
	    p = &arg;
	    printf(*p,*(p+1));
	}
	main()
	{
	    foo("here %s\n","it is");
	}
and instead of getting the actual calling stack address (stored above
the return address) of the first arg...it will give me the address of
a copy....so the result will be instead of
		here it is
I will get
		here <garbage>
where garbage is a string print out of some bad pointer...which in reality
is the location after the copied stack value...which is random...may even
be p itself since it is allocated next in the routine locals. Check itout..
use CC /MACHINE/LIST and see for your self.

-Rudy

info-vax@ucbvax.ARPA (02/20/85)

From: sasaki@harvard.ARPA (Marty Sasaki)

I'm using the 1.5 version of the C compiler. Maybe your problem is because
it is an alpha test version of the compiler?

For the main

	main() { foo("This %s\n","is it"); }

the compiler generates code something like:

	moval	$C_STRING_CONSTANT,ap
	pushal	9(ap)
	pushal	(ap)
	calls	#2,foo
	movl	#1,0
	ret

For foo:

	foo(arg) int arg;
	{	int *p;
		p = &arg;
		printf(*p,*(p+1));
	}

and the compiler genrates something like

	movab	4(ap),r1
	addl3	#4,r1,r0
	pushl	(r0)
	pushl	(r1)
	calls	#2,printf
	ret

This seems completely correct and does produce the desired results when
compiled and run, i.e. "This is it\n" gets printed.

		Marty Sasaki

info-vax@ucbvax.ARPA (02/20/85)

From: Rudy.Nedved@CMU-CS-A.ARPA

Thanks to Marty Sasaki and Chris Ho. I wish I had heard the rumor or
had known we had a beta test version of the C compiler. A co-worker
told me later after he saw the Info-Vax mail...

I have sent an SPR (maybe it should have been a QAR?) in about the
address-of-function-arg "bug" with a cure of "copy 'em all" as
suggested by Mr. Firth (first name escapes me). As far as my
applications are concerned, copying all the args IF &functionarg is
done will work.

In general the DEC X2.0 C compiler and the DBG support is much better
then the Unix 4.x C compiler and sdb. Better error messages. Good
code generation.  To bad forking things under VMS and looking up
files is (at least seems) so expensive...MMS (Make) takes eons it
seems.

The best part was it took me only 7 long days to get CMU Unix Emacs
up on our 3.6 VMS ignoring the one serious bug I encountered. It does
not have subprocesses for command windows but ain't bad. [Those
features come later after I learn more about RMS/VMS and the little
tricks that Eunice seems to know about.]

Thanks again,
-Rudy