I designed and wrote the SunOS 4.x POSIX compliance.  Theo is right that 
it is a bit lax - there was a requirement for the releases (SunOS 4.1) that
binaries from SunOS 4.0 not break.  This was kind of a pain because requires
that you be a session leader in order to acquire a controlling terminal.
Well, to be a session leader you had to call setsid().  Setsid() was 
a POSIX interface; it did not exist in SunOS 4.0.  Binaries couldn't
break.

So what do you do?  I thought about all the ways that programs expressed
their intereste in getting a new controlling terminal.  They are

	setpgrp(0, 0);
	ioctl(0, TIOCNOCTTY, 0);

Both of these result in the kernel calling setsid() on your behalf.  It
turns out that that is sufficient to get old programs to work and to
have POSIX session semantics.  

Almost.  The SESS_SYS / SESS_NEW stuff below is so that the kernel knows
whether you called setsid() directly or not.  If you say setsid(); setsid();
the second one returns an error.  If you say setpgrp(0, 0); setsid();
the setsid() should not fail (even though we are mixing BSD setpgrp() with 
POSIX setsid()).  It should not fail because you have not called it yet.
It always succeeds exactly once.

So, I suck at explaining stuff before my coffee.  If this is not clear,
send some more mail.

By the way - tons of stuff out there will break if you do not do the
same hack.  X11, emacs, screen, anything that diddles ttys.  Noone has
updated their stuff for POSIX in this regard.

$ >>>Just trying to run xterm and I get a "xterm: no available ptys" message.
$ >>>Using "ktrace" and looking at the xterm source, there "seems" to be a
$ >>>difference in TIOCGPGRP handling ...
$ >>
$ >>I have the *exact* same problem.
$ >
$ >Sorry - you're likely to have that problem for a long time.  The SunOS
$ >pgrp/session code is more lax and forgiving than POSIX says it should be.  Our
$ >code is ... probably closer to POSIX.  I presume that SunOS made their pgrp's
$ >lax so that SunOS 3.5 binaries could run, or perhaps SunOS 4.0 binaries.
$ 
$ Actually, I was beginning to wonder if the session management stuff (which I
$ think was new as of SunOS 4.1; I remember having to change the port of Jeff
$ Forys' "skill" super-kill program to accomodate it, since it refs the proc
$ structure) was getting in the way perhaps.  If you check out the SunOS 4.1.x
$ <sys/session.h>:
$ 
$ ...
$ #define SESS_SYS        0               /* Default session id (no tty) */
$                                         /* Also: goto old sess0, a la BSD */
$ #define SESS_NEW        1               /* New session wanted, a la posix */
$ ...
$ 
$ How does NetBSD handle tty sessions?  I assume the latter ...
$ 
$ >Unfortunately it will fail to run a SunOS-compiled xterm if your shell is csh.
$ >Some have reported that using `sh' works (?)
$ 
$ I tried that ... :-(

------------------------------------------------------------------------------