Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bbn!oberon!sdcrdcf!otto!mirror!datacube!ftw
From: ftw@datacube.UUCP
Newsgroups: comp.lang.c
Subject: Re: MSC-all C's
Message-ID: <102600019@datacube>
Date: Fri, 13-Nov-87 17:22:00 EST
Article-I.D.: datacube.102600019
Posted: Fri Nov 13 17:22:00 1987
Date-Received: Sun, 15-Nov-87 20:44:21 EST
References: <3094@rosevax.Rosemount.COM>
Lines: 47
Nf-ID: #R:rosevax.Rosemount.COM:-309400:datacube:102600019:000:1854
Nf-From: datacube.UUCP!ftw    Nov 13 17:22:00 1987


richw@rosevax.UUCP writes:

> I have two questions:

>   1) What happens in C when a function returns a value which the
>      calling line does not assign to a variable? Where does this
>      value end up? (example: strcpy(str1,str2); ) Could someone
>      explain the process that is gone through when a function is
>      called?

Usually, a function return value gets stuck in a spare register.  The
compiler vendor will will have a standard mechanisim for passing back
return values for functions.  For instance, most 68K C compilers that
I have come across will stick function returns in register d0; Whitesmiths
uses d7, etc.  Aggregates are more complicated.  If the caller does not
use the return value, it will remain where it was put until overwritten
by something else.

In a stack based machine, when a function is called, all the args to that
function are pushed on the stack in some agreed-upon order, along with
the return address.  The called function accesses its arguments by using
offsets from the current value of the stack pointer.  The stack is unwound
when the called function returns.


>  2) Specific to IBM Pc compilers. I am trying to write some
>     disk routines (using DOS interrupts <-sp?) I am not sure which
>     memory model I will need for a large application program I will
>     soon write. How can I generalize these routines to work with any
>     memory model. I am specifically concerned with pointers (near/far).

Someone else will have to take this one.  I do get the impression that
such a thing would be at least rather tricky.


> Thankyou in advance.
> Rich Wagenknecht



				Farrell T. Woods 

Datacube Inc. Systems / Software Group	4 Dearborn Rd. Peabody, Ma 01960
VOICE:	617-535-6644;	FAX: (617) 535-5643;  TWX: (710) 347-0125
INTERNET: ftw@datacube.COM
UUCP: {rutgers, ihnp4, mirror}!datacube!ftw