🚀 go-pugleaf

In article <3vp60e$o8c@solutions.solon.com> seebs@solutions.solon.com (Peter Seebach) write>
> Hmm.  I guess, my advice would be to define that the "irrelevant" values
> are returned as zero

Requiring this would introduce some inefficiency. I don't think many
compilers could use the "as-if" rule to remove the zero-assignments if the
values were never read by the calling function.

> I think we're disagreeing about the use of "undefined".  The use of
> an uninitialized float is undefined behavior, right?  So, are you
> advocating undefined behavior as part of the normal functioning of the
> routine?  I can see "I don't care what value goes here", I can't see
> "I want this undefined".

You are right, I meant to propose a "don't care" result (like the initial
value of an auto variable).
 
[..]
> >On the topic of hidden costs: _current_ C has an "invisible overhead", as
> >the return value is copied to some unnamed location by the returning
> >function, and then read from that location when the calling function uses
> >the value.  Introducing one or more explicit return parameters would remove
> >this "hidden variable"!
> 
> Hmm.  Interesting point.  However, since *how* it's done in current C
> is not clear, and you aren't supposed to try to guess, making it explicit
> could be a Bad Thing.

I guess my impression of the calling mechanism is tainted by exposure to
C++, where, if memory serves (eek! my ARM is at home!), a return involves
the invokation of a copy constructor.

-- Markus (one of these days, I _have_ to fork over the money for an ANSI C
	   standard text ;-)