🚀 go-pugleaf

This is in response to BS's very helpful response on
problems involving integrating c++ with standard c.

Problem 1:


>	/* THIS IS STANDARD C */
>	extern void foo();
>
>	main()
>	{
>  	int x = 23;
>  	foo(&x,&x);
>	}
>
>> ----------------------------
>
>	/* THIS IS C++ */
>	#include <sys/types.h>
>	#include <sys/stat.h>
>
>	int lstat(char*, stat*);
>
>	void foo(int *x, int *y)
>	{
>		struct stat stbuf;
>		lstat("/etc/motd", &stbuf);
>	
>		return;
>	}
>
> ------------------------------------
> 
> and they are compiled as:
> 	% cc -c main.c
> 	% CC -c foo.c main.o
> 
>
> When I write into &stbuf via the lstat, the foo's return
> address seems to get clobbered, and the program core
> dumps with an illegal instruction at the return statement,
> with the values for x and y getting set to nil.
>

BS's response:
>>I conjecture that you are using a SysV declaration of ``struct stat'' in
>>/usr/include/CC/sys/stat.h from C++ and a BSD4.? declaration ``struct stat''
>>in /usr/include/sys/stat.h from C. Since the BSD stat is larger than the SysV
>>stat you are in trouble. Please modify /usr/include/CC/sys/stat.h to fit
>>your system.

Yes. Exactly.  I have since converted all of the 4.3 /usr/include
files to work with C++.  

> More annoyingly, the following core dumps in ostream...
> 
> void foo(int* x, int* y)
> {
> 	cerr << *x;
> 	cerr << *y;
> }
> 
> when it is called from a C program (for reasons that are beyond
> me... I can guess on the first example, but on this one, I have no
> idea).

BS's response:

>>I conjecture that you did not load the program using CC so that the constructors
>>initializing cin, cout, and cerr were not called. A similar effect (core dump
>>on the first C++ stream I/O operation) can be obtained by not compiling main()
>>by CC.

You got it.
Yes, they were loaded properly.
The problem seems to only happen when you call a C++ function from 
standard C main().  If I reverse the calling sequence, things work.
I guess, in retrospect, this makes sense.

> Since I am writing a fairly substantial package that uses
> somebody else's RPC (with stubs generated in C) routines,
> the fact that this stuff doesn't work is causing me numerous
> headaches.
>
>>Sorry about that, and thankyou for complaining where others can benefit from
>>your experiences. It ought to work. Please confirm or complain again.

No apologies needed. 
In general, integrating large amounts of C code (> 500 lines) with
large amounts of C++ code (> 5000 lines), seems to work ok.  I
have some nasty sed/awk scripts to clean up the RPC generated headers
for the stubs to make them both C and C++ compatible, and there are still some 
strange problems with passing enumerated types between C and C++,
but things are going well, and I don't think I would have
been able to handle this much code as effectively had I done
it in C.  (though I still have to convince my advisor
that doing this in C++ was a good idea...... )

I have an unrelated (possibly naive) question.  I am using dbx
to debug my code, and I was rather surprised to find that
dbx can relate C++ statements (not those in the ..c files)
to the pc, so I can smoothly trace execution from the debugger.
I have to do all the name translation by hand (ie. Class::function
becomes Class_function, prepending _auto_ to most things, etc...),
but dbx is able to map my .c source code to the executable so
I can trace through things and see the original C++ code.
Since it is really the ..c files that are being compiled with
/bin/cc, how is dbx able to do this??  This is not a complaint.


	Brian Bershad
	University of Washington Computer Science
	bershad@ucbvax.berkeley.edu || ucbvax!bershad || brian@uw-june.arpa