[comp.lang.c] Problem with functions returning structs

boetsch@lan.informatik.tu-muenchen.dbp.de (Ernst Boetsch) (09/25/89)

Subject: Problem with functions returning structs

[ Sorry if this problem has already been reported ]

Hello,

I had (portability ?) problems with functions returning structs as
result:
On my VAXstation with ULTRIX 3.0 I use the dbm(3) database package
which is compiled with the native cc.  dbm(3) uses the struct
	typedef struct {char *dptr; int dsize;} datum;
and functions like
	datum fetch(datum key);
	datum nextkey(datum key);

If I compile my program (which uses dbm(3)) also with the native cc all
is fine.
Compiling it with GNUcc leads to runtime errors.

If I change the code conforming to the declaration
	datum *fetch(datum key);
	      ^
(not obeying the manual; as if fetch returns a pointer to the struct)
the GNUcc executable works fine but not the native cc executable.
I have the analogous problem with the GNUcc compiled database package
and the program compiled with the native cc or GNUcc.

I managed the problem by compile options controlling
'#ifdef ... #else ... #endif'.

Now my questions:
- Is this behavior a portability problem (I think so)
  or did I make a mistake
  or does GNUcc generate wrong code?
- What is the best (most portable) way to handle this problem if it is
  a portability problem.
- Is there a similar problem with structs as function parameters (in my
  environment both GNUcc and the native cc handled structs as
  parameters in the same way)?

Thanks in advance.
	Ernst Boetsch

Ernst N. Boetsch,  Inst. fuer Informatik, Technische Universitaet Muenchen
		   Postfach 20 24 20,	  D-8000 Muenchen 2,  West Germany
boetsch@infovax.informatik.tu-muenchen.dbp.de	     Tel: +49 89 2105 2385
boetsch%infovax.informatik.tu-muenchen.dbp.de @ {relay.cs.net, unido.uucp}

davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/26/89)

In article <816@tuminfo1.lan.informatik.tu-muenchen.dbp.de>, boetsch@lan.informatik.tu-muenchen.dbp.de (Ernst Boetsch) writes:
|  Now my questions:
|  - Is this behavior a portability problem (I think so)
|    or did I make a mistake
|    or does GNUcc generate wrong code?

  I believe that the way gcc and cc handle functions returning struct is
not the same. If this is the case then you have to either generate
incorrect C (as you have) to fool the compiler into expecting the native
cc conventions, or recompile every library you use with gcc.

  Using libraries compiled with one compiler with programs compiled with
another is always a possible cause of problems with calling sequences.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon

bitbug@lonewolf.sun.com (James Buster) (09/27/89)

In article <816@tuminfo1.lan.informatik.tu-muenchen.dbp.de> boetsch@lan.informatik.tu-muenchen.dbp.de (Ernst Boetsch) writes:
>I had (portability ?) problems with functions returning structs as
>result:
>On my VAXstation with ULTRIX 3.0 I use the dbm(3) database package
>which is compiled with the native cc.  dbm(3) uses the struct
>	   typedef struct {char *dptr; int dsize;} datum;
>and functions like
>	   datum fetch(datum key);
>	   datum nextkey(datum key);
>
>If I compile my program (which uses dbm(3)) also with the native cc all
>is fine.
>Compiling it with GNUcc leads to runtime errors.

[stuff deleted]

>Now my questions:
>- Is this behavior a portability problem (I think so)
>  or did I make a mistake
>  or does GNUcc generate wrong code?
>- What is the best (most portable) way to handle this problem if it is
>  a portability problem.
>- Is there a similar problem with structs as function parameters (in my
>  environment both GNUcc and the native cc handled structs as
>  parameters in the same way)?

Basically, GNU cc uses a different return mechanism for functions that
return structures. It is necessary to give the flag `-fpcc-struct-return'
when you desire to use the return mechanism of the native compiler.
This flag is documented in gcc.texinfo, which should be contained in the
GNU cc distribution you received.

>Thanks in advance.
>	   Ernst Boetsch
>
>Ernst N. Boetsch,  Inst. fuer Informatik, Technische Universitaet Muenchen
>	      Postfach 20 24 20,	  D-8000 Muenchen 2,  West Germany
>boetsch@infovax.informatik.tu-muenchen.dbp.de	     Tel: +49 89 2105 2385
>boetsch%infovax.informatik.tu-muenchen.dbp.de @ {relay.cs.net, unido.uucp}


--
--------------------------------------------
	     James Buster
	Mad Hacker Extraordinaire
       bitbug@lonewolf.ebay.sun.com
	 bitbug%lonewolf@sun.com
	 sun.com!lonewolf!bitbug
--------------------------------------------

piet@cs.ruu.nl (Piet van Oostrum) (09/27/89)

In article <816@tuminfo1.lan.informatik.tu-muenchen.dbp.de>, boetsch@lan (Ernst Boetsch) writes:
 `I had (portability ?) problems with functions returning structs as
 `result:
 `Now my questions:
 `- Is this behavior a portability problem (I think so)
 `  or did I make a mistake
 `  or does GNUcc generate wrong code?
 `- What is the best (most portable) way to handle this problem if it is
 `  a portability problem.

If your GCC is properly configured there is a switch  -fpcc-struct-return
which you can supply on your gcc command line to get the calling sequence
required by cc.

 `- Is there a similar problem with structs as function parameters (in my
 `  environment both GNUcc and the native cc handled structs as
 `  parameters in the same way)?

There should be no problem with structs as parameters.
-- 
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht,  The Netherlands.
Telephone: +31-30-531806      Internet: piet@cs.ruu.nl
Telefax:   +31-30-513791      Uucp: uunet!mcvax!hp4nl!ruuinf!piet