🚀 go-pugleaf

Christian Lassem wrote:
> I am not sure this is related, but in GCC you can implicitly declare the
> _return_ value with a name.
> 
> So:
>         typedef struct { int n; double y; } ret_type;
> 
>         ret_type frexp(double x) return r /* Return name. */
>         {
> 
>                 r.n = ...;
>                 r.y = ...;
>         }
I think we might be straying from the original intent here, but this is
not a GCC invention, it is a C++ mechanmism. Basically, the actual
calling standards differ widely among implementations. As mentioned
earlier, some implementations use registers to pass values rather than
the stack, and, likewise, use registers to return values. In the case of
multiple values, such as the ldiv_t library function, the function
returns a struct which contains related informaiton. I generally prefer,
in this case, a function returns a status (success or failure), and the
actual results be returned in a struct (or other variables) whose
address is passed as a parameter. The "right" way to do it tends to be a
style issue. Returning a struct generally involves copying the data from
the function's local data (normally on the stack), to wherever the
return value is stored (implementation defined), then the data is copied
to the object of the assignment. For a small struct and a good
optimizing environment, this can be done in registers. For larger
structs, the data is copied twice. Some of the POSIX reentrant functions
pass in an additional pointer to output data. For example, the ctime
function returns a pointer to a string. Since this string is in static
data, the ctime function is inherently not threadsafe. So, the _r
version of the function requres the caller to supply storage for the
string:
 char *ctime_r(
          const time_t *timer,
          char *buffer) ;




-- 
Jerry Feldman              Digital Unix Development Environment
Digital Equipment Corp.    Nashua, NH 03062-9987      
gaf@zk3.dec.com, gaf@bcs.org