From owner-cvs-all  Tue Feb 17 14:53:32 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA09766
          for cvs-all-outgoing; Tue, 17 Feb 1998 14:53:32 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA09299;
          Tue, 17 Feb 1998 14:51:31 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id JAA29472;
	Wed, 18 Feb 1998 09:49:26 +1100
Date: Wed, 18 Feb 1998 09:49:26 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199802172249.JAA29472@godzilla.zeta.org.au>
To: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG,
        jkh@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/gen getpass.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

>  Modified files:        (Branch: RELENG_2_2)
>    lib/libc/gen         getpass.c 
>  Log:
>  MFC: more fascist signal blocking.
>  
>  Revision  Changes    Path
>  1.5.2.1   +11 -40    src/lib/libc/gen/getpass.c

Actually, it is to spell the signal handling POSIXly, and as an unlogged
side effect, to (uncleanly) back out revisions 1.2 and 1.3.  Revisions 1.2
and 1.3 break the signal handling for callers that ignore signals, e.g.,
login(1) and passwd(1).  Login was kludged to not ignore signals for
the getpass() call and in surrounding code so that the broken getpass()
didn't affect it.  It's not clear what happens if a previously-ignored
signal occurs while the surrounding code is running.  A correct version
of revisions 1.2 and 1.3 would only catch signals if signals are being
defaulted.  It's not clear what it should do if signals are being caught.
Keeping the historical behaviour would be safest.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message