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