Re: [PATCH] compat: add a getpass() compatibility function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 19.05.2011 um 14:17 schrieb Erik Faye-Lund:

> But I can't help to think that this implementation of getpass looks a
> bit heavy, especially since we already have our own getpass
> implementation in compat/mingw.c.

> Do we really need two implementations? Wouldn't it be better to factor
> out the mingw-version to a separate source file, and then improve it?

Yes, I agree very much that it would be nicer to have a common version.


> Windows doesn't have /dev/tty, but the logic in this version handles
> that by using stdin/stderr instead. The signal-stuff has a comment
> that indicates it might not even be correct. tcgetattr/tcsetattr isn't
> supported on Windows, but it's not needed if we use getch (as the
> version in compat/mingw.c does). POSIX/curses getch respects the
> echo-setting, while Windows getch never echo.

Sadly, there is no curses.h on Android. So as my goal is compiling on Android, it wouldn't help much to create another dependency on curses.h.

So we would still need the /dev/tty opening and the tcgetattr/tcsetattr stuff, which would result in a very cluttered code if combined with getpass from compat/mingw.c. So I think, it will be easier to keep the two separated.

I do share your concern about the license and the heavyness of the code, so I switched to the getpass.c from uClibc and prepared a new patch. It is LGPL-v2.1 licensed, which seems like it has to be added anyway. I also tried to remove unused code from the new version as good possible.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]