Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky

[RVP <rvp%SDF.ORG@localhost>]

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

From: RVP <rvp%SDF.ORG@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, martin%netbsd.org@localhost, roland.illig%gmx.de@localhost,
        Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>, vezhlys%gmail.com@localhost
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
 sticky
Date: Mon, 23 Aug 2021 08:35:14 +0000 (UTC)

 On Fri, 20 Aug 2021, Andreas Gustafsson wrote:
 
 > RVP wrote:
 >> Re: progress.c 1.24: This test which you modified is not needed:
 >>
 >>  	if (deadpid == -1 && errno == EINTR)
 >>  		continue;
 >>
 >> By ths point all read/writes have finished, and `outpipe[1]' has
 >> been closed. So you can stop the progress bar code right after the
 >> `while (1)' loop and no interrupts can occur. This is what my
 >> initial patch did.
 >
 > Closing outpipe[1] eliminates one source of signals, but I don't see
 > any obvious way of proving that there can be no others.
 >
 
 Not sure what you mean here: Only caught signals (ALRM and PIPE--but the
 PIPE handler causes a termination) can cause wait() to return an EINTR.
 If the progress bar is turned off, and there are no writes, wait() can't
 come back with a -1 and EINTR. Which signals are you worried about here?
 
 >> The subsequent patch is more of the same: dotting
 >> the Is and crossing the Ts--very straight-forward stuff, but I
 >> wanted to ensure that progress(1) exited with a proper error code
 >> everytime.
 >
 > And, it appears, to do various unrelated cleanups at the same time.
 > Don't get me wrong, cleanups are welcome, but lumping them all
 > together in a single patch, or even a wholesale replacement of the
 > entire source file, makes them hard to review and to separate into
 > individual commits with appropriate commit messages.
 >
 
 The diff is slightly large, but, most of the changes are simple, obvious
 ones, and the core logic is practically the same, so hardly a wholesale
 replacement...
 
 On Fri, 20 Aug 2021, Christos Zoulas wrote:
 
 > That's a good change, replacing a non-portable ioctl call with a posix 
 > terms function call.
 >
 
 That was the intent, yes.
 
 -RVP