Apparently, reading a password is a very non-trivial task. There is POSIX getpass, but unfortunately it was deprecated, because, allegedly, it is very easy to implement it your self (LOL).
What we currently have kinda works, but it has the following problems:
It keeps the original input encoding instead of normalising it to UTF-8, which means that the same sequence of key presses on OSes with different locale encodings (e.g. UTF-16 on Windows vs. UTF-8 on Linux) will result in different passwords as bytes. Pretty much every password reading function for C/C++ that I could find has this problem (in higher-level languages it is usually not a problem, since all input goes via a Unicode-aware string type and is then encoded to UTF-8 bytes).
It does not do anything about signals. In reality, we want to handle signals and restore the terminal state, and then, if we were paused and resumed, we want to reset all our state and start reading from scratch.
This sounds like a useful C library to have in general.
Apparently, reading a password is a very non-trivial task. There is POSIX
getpass
, but unfortunately it was deprecated, because, allegedly, it is very easy to implement it your self (LOL).What we currently have kinda works, but it has the following problems:
It keeps the original input encoding instead of normalising it to UTF-8, which means that the same sequence of key presses on OSes with different locale encodings (e.g. UTF-16 on Windows vs. UTF-8 on Linux) will result in different passwords as bytes. Pretty much every password reading function for C/C++ that I could find has this problem (in higher-level languages it is usually not a problem, since all input goes via a Unicode-aware string type and is then encoded to UTF-8 bytes).
It does not do anything about signals. In reality, we want to handle signals and restore the terminal state, and then, if we were paused and resumed, we want to reset all our state and start reading from scratch.
This sounds like a useful C library to have in general.