🚀 go-pugleaf

In article <3vnqah$1ev@news.cs.tu-berlin.de>,
Markus Freericks <mfx@cs.tu-berlin.de> wrote:
>A function that determines the intersection between two line segments,
>determined by four float arguments (two points) each, returning an enum
>flag (no intersection / one point intersection / line segment intersection)
>and four float results, of which either none, two, or all four are
>defined.

Hmm.  I guess, my advice would be to define that the "irrelevant" values
are returned as zero.

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".

>Most hardware _has_ a clever trick for return values: registers. Most
>compilers use a register to pass the return value up, no?

Depends.  I've seen a fair number use the stack, when there is one.  And,
of course, they may use that register for storage until given a specific
return.  Consider:

	retval = x;
	fn_which_uses_same_register();
	return;

I'd rather have the returned value explicit, myself.

>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.

-s
-- 
Peter Seebach - seebs@solon.com || seebs@intran.xerox.com --- C/Unix
proto-wizard -- C/Unix questions? Send mail for help.  No, really!
Copyright 1995 Peter Seebach.  Not for distribution through Microsoft Network.
a^n+b^n=c^n has integer solutions {a, b, c, n} only for n<=2.  To prove, assume