Re: pkg/53229 (textproc/py-expat does not build w/o terminal session)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/53229; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/53229 (textproc/py-expat does not build w/o terminal session)
Date: Wed, 10 Apr 2019 03:24:14 +0700

     Date:        Tue,  9 Apr 2019 17:10:55 +0000 (UTC)
     From:        leot%NetBSD.org@localhost
     Message-ID:  <20190409171055.253647A1DC%mollari.NetBSD.org@localhost>
 
   | Problem analyzed, patch fixes the problem but not committed
   | because it would be nice if anyone more familiar with dup, fstat
   | semantics and standards can confirm that's actually ok!
 
 The simple answer to that is that it is obviously OK to use any
 technique you like (which works) to test if an fd is valid or not.
 So, the patch seems to be fine (switching NetBSD to use fstat() rather
 that dup()).
 
 On the broader question of whether the way NetBSD treats revoked terminals
 is POSIX compatible or not, from a quick glance at things, I'd say not.
 (However it is how BSD has done it for a long time, and I will ask on the
 austin group list for opinions from others).
 
 But POSIX XBD (basic definitions) section 11.1.3 ("The Controlling Terminal")
 says:
 
 	When a controlling process terminates, the controlling terminal
 	is dissociated from the current session, allowing it to be
 	acquired by a new session leader.
 
 That's what happens when the login shell exits.
 
 	Subsequent access to the terminal by other processes in the earlier
 	session may be denied, with attempts to access the terminal treated
 	as if a modem disconnect had been sensed.
 
 And this is what we are more or less achieving by the revoke, or
 it is with the same objective.
 
 
 And then, in XBD 11.1.10 ("Modem Diosconnect")
 
 	If a modem disconnect is detected by the terminal interface for
 	a controlling terminal, and if CLOCAL is not set in the c_cflag
 	field for the terminal (see Section 11.2.4, on page 209), the
 	SIGHUP signal shall be sent to the controlling process for which
 	the terminal is the controlling terminal. Unless other arrangements
 	have been made, this shall cause the controlling process to
 	terminate (see exit( )).
 
 That part is it is not really relevant, the background processing setup
 includes ignoring SIGHUP.  So here the state of CLOCAL is irrelevant
 (which is what would be wanted anyway.)
 
 	Any subsequent read from the terminal device shall return the
 	value of zero, indicating end-of-file; see read( ). Thus, processes
 	that read a terminal file and test for end-of-file can terminate
 	appropriately after a disconnect. If the EIO condition as specified
 	in read( ) also exists, it is unspecified whether on EOF condition
 	or [EIO] is returned. Any subsequent write( ) to the terminal device
 	shall return -1, with errno set to [EIO], until the device is closed.
 
 But that suggests that returning EBADF for a revoked terminal is not the
 POSIX specified approach, the fd should remain valid, and simply be unable
 to perform any I/O.   (Since ioctl() is not a POSIX interface, what happens
 with attempts to do that is clearly not specified.    However some operations
 that are typically implemented using ioctl() are specified, and those make
 no mention of returning an error for a terminal after a "modem disconnect".)
 
 From that I would suspect that both dup() and fstat() should continue to
 work on a revoked terminal (no errors) and that a later I/O request should
 fail (what this would do to python I have no idea, as by changing the
 dup() to fstat() for NetBSD suggests that the error is wanted, which if I
 am correct about posix, should not be generated from either.   Of course,
 this might only matter if some later call generates EBADF, and EIO or EOF
 might be treated differently.
 
 And as an aside, I don't know about MacOS, but on NetBSD, fcntl(F_GETFL)
 would be a cheaper (cheaper even than dup, as no close() is needed) way to
 test whether the fd is valid or not.   When EBADF is to be returned, all
 of them are equally cheap, but when there is no error, fstat() copies out
 a bunch of unwanted data, dup() returns an fd that needs to be closed, and
 fcntl(F_FETFL) simply returns an int which is easily ignored.
 
 kre
 
 I will append more to this PR if any meaningful response comes from the
 austin group.