[net.lang.c] return

ajs@hpfcla.UUCP (05/10/84)

> In all seriousness, the more parentheses there are in an
> expression, the harder it is to read.  I personally find the
> layout
>	y = x == 5 ? 1 : 0;
> much clearer than
>	y = (x == 5) ? 1 : 0;

In all seriousness, I wholly, absolutely, irrevocably disagree with you,
and hope I never have to maintain any of your code, so there.

It's obviously a religious discussion.  On the bright side, award yourself
two points if you care enough to consider coding standards at all.  The only
real losers are those who don't even think about it.

Alan (we can still agree on something) Silverstein

ok@edai.UUCP (05/22/84)

    I never use return(expr) or return (expr) on the grounds that
it looks like a FUNCTION CALL, and it isn't.  Most of the time
you are saying return TRUE or return FALSE or return <variable>,
and the extra junk doesn't do anything for you.

    Do people who like return(e) also #define Goto(x) goto x
and then write Goto(L), Break(), Continue() and so on?  If not,
why not?

    I'd prefer keywords like if ... then instead of if (...).
This principle that things which aren't function calls shouldn't
look like function calls has lead me to adopt the practice of
	#define skip
	while (this_does_everything) skip;
instead of
	while (this_does_everything) ;
I apologise for letting code get out into the world without this
readability feature, and promise not to do it again.

    In all seriousness, the more parentheses there are in an
expression, the harder it is to read.  I personally find the
layout
	y = x == 5 ? 1 : 0;
much clearer than
	y = (x == 5) ? 1 : 0;
Yes, a policy of avoiding parentheses can make very large expressions
hard to read, but adding unnecessary parentheses only makes it worse;
the answer is to break up big expressions.  (That doesn't hurt most
compilers either.)

rich@mit-bugs-bunny.arpa (01/25/86)

I'm on a binary only 3b2/300 running SV.2.2 so...

What's the difference between leaving main by return() vs exit() vs _exit()?
I mean in reality, by proposed standards (X3J11 can you hear me?), and
functionally (like on my machine).  Who closes file descriptors?  Who reclaims
memory?  What about shared memory?  What is a gate 4, 8?

K. Richard Magill

gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/26/86)

> I'm on a binary only 3b2/300 running SV.2.2 so...
> 
> What's the difference between leaving main by return() vs exit() vs _exit()?
> I mean in reality, by proposed standards (X3J11 can you hear me?), and
> functionally (like on my machine).  Who closes file descriptors?  Who reclaims
> memory?  What about shared memory?  What is a gate 4, 8?

There is no difference between reality and the proposed standards.

If main() is left via a return statement, the effect is exactly
the same as termination via invocation of exit() with the return
value used as the parameter to exit().  exit() is required to
flush STDIO output buffers and do any other required cleanup.
_exit() directly terminates the process without performing any
extra actions along the way.  _exit() is not available in all C
implementations, although it is required on UNIX systems.

"File descriptor" is a UNIX-only concept.  Open file descriptors
are closed by the UNIX kernel when a process terminates.  The
kernel is also responsible for memory allocation and sharing.

GATE is similar to a subroutine jump except it switches into the
kernel (acquires new PC & PSW), vectored through tables indexed by
R0 and R1.  This constitutes a "service call" or "system call".
_exit() is normally implemented as a small piece of assembly-
language code that simply invokes the appropriate system call,
perhaps "gate 4,8".  exit() normally calls _cleanup(), perhaps
runs registered onexit handlers, then invokes _exit().

brooks@lll-crg.ARpA (Eugene D. Brooks III) (01/26/86)

In article <178@rexago1.UUCP> rich@rexago1.UUCP (K. Richard Magill) writes:
>I'm on a binary only 3b2/300 running SV.2.2 so...
>
>What's the difference between leaving main by return() vs exit() vs _exit()?
return(i) from main is the same as exit(i), exit(i) flushes all the open file
descriptors and then calls _exit(i).  _exit(i) crashes and burns.

jsdy@hadron.UUCP (Joseph S. D. Yao) (01/26/86)

In article <178@rexago1.UUCP> rich@rexago1.UUCP (K. Richard Magill) writes:
>What's the difference between leaving main by return() vs exit() vs _exit()?

Functionally, return and exit should be identical.  Your 'lint'
(s5r2.0v2) prob'ly complains if you use exit() tho.  The code goes
roughly like:
[C header, crt0.s:]
	push	envp
	push	argv
	push	argc
	call	$3, _main
	push	r0
	call	$1, $_exit
	sys	$exit_system_call
	halt
Note that exit(main(argc, argv, envp)) is the effect.

The exit() code resembles:
exit(val)
  int val;
{
	register FILE *fp;

	for (fp = _iob; fp < &_iob[NIOBUFS]; fp++)
		if fp has been opened
			fclose(fp);
	_exit(val);
}
..........
__exit:
	move	arg to r0
	sys	$exit_system_call

Shared and local memory are reclaimed by the kernel after an exit()
system call.

>                               ...  What is a gate 4, 8?

Got my curiosity piqued.
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}