>
>  | #2 is possible, but a little yucky as you say.  It's also probably about
>  | as hard to get right as my #5 too.
>
>It shouldn't be, that way (have getpass() catch signals and DTRT) is
>the correct solution.
>
>Anything which is messing with the terminal state should be doing that.

Actually I disagee that any library routine should start engaging signal
handlers. Absolutely nothing in the libary does so today (that I could find
with a quick scan) so this would be a pretty radical departure to start doing.

Plus, what are you going to do with a SIGINT? Clean up and then either call
the old handler or exit? Exiting from a library routine is even worse. That's
a prime example generally of bad bad design.

>
>  | Of course users of getpass() must be fixed up to catch SIGINT and to
>  | properly reset the terminal modes when it is triggered....
>
>No, if getpass() is going to meddle it is getpass()'s job to unmeddle.

I agree from a high level view, but if there's no clean way to do that without
getpass replacing signal handlers for every possible interrupt case then
that's no better. A *lot* of library functions when SIGINT'd will leave things
in an indeterminate state. In this case it's been identified and documenting
it would be a huge step forward.

>  | The code in 4.3BSD-Reno has the comment:
>  | 
>  |         /*
>  |          * note - blocking signals isn't necessarily the
>  |          * right thing, but we leave it for now.
>  |          */
>
>That's also true - it is just the easy way, and close enough...

Actaully no. By blocking it creates behavior that I've never seen on any 
other system I've tried to run su on. Everything else either su catches the
signal and fixes stuff or it leaves the terminal in non-echo mode. But, it
doesn't require ^C\n anywhere else I've seen to abort.