Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> > What's the reason that you mention "from /dev/tty (or stdin)"? Don't other
>> > implementations read from /dev/tty or stdin?
>>
>> Without that part, I found to description to be somewhat ambiguous: it
>> could be interpreted
Bruno Haible <[EMAIL PROTECTED]> wrote:
> ..., Solaris 10 (8, even less than PATH_MAX), Cygwin (128).
I fixed the typo:
* doc/glibc-functions/getpass.texi (getpass): s/PATH_MAX/PASS_MAX/.
Simon Josefsson wrote:
> > What's the reason that you mention "from /dev/tty (or stdin)"? Don't other
> > implementations read from /dev/tty or stdin?
>
> Without that part, I found to description to be somewhat ambiguous: it
> could be interpreted as a function that returns a random password, not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Josefsson wrote:
> Another problem that I discovered is that gnulib's getpass.c inhibits
> signals, so the user cannot press ^C/^Z. This is even more of a problem
> when the user needs to type the same password twice: the process may be
> stuck
Micah Cowan <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> I'm not sure it is a good idea to recommend use of getpass, possibly
>> gnulib could offer a better interface. It could have a parameter to ask
>> for confirmation of the password internally. However, I will use
>> getpass for n
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Thanks, below is an updated patch.
>
> OK. Are you going to commit that?
I'm pushing it now, thanks for comments.
>> -Portability problems not fixed by Gnulib:
>> +Portability problems fixed by Gnulib module @code{getpass-gnu}:
Simon Josefsson wrote:
> Thanks, below is an updated patch.
OK. Are you going to commit that?
> -Portability problems not fixed by Gnulib:
> +Portability problems fixed by Gnulib module @code{getpass-gnu}:
> @itemize
> @item
> -This function is missing on some platforms:
> -mingw, BeOS.
> +The
Simon Josefsson wrote:
> I'm not sure it is a good idea to recommend use of getpass, possibly
> gnulib could offer a better interface. It could have a parameter to ask
> for confirmation of the password internally. However, I will use
> getpass for now since I don't want to introduce a lot of cha
Simon Josefsson <[EMAIL PROTECTED]> writes:
>>> Another way of looking at this is that
>>> there is a memory leak in the gnulib 'getpass' module.
>>
>> It's hard to argue this way: getpass() is not specified by a standard.
>
> It is a memory leak regardless of whether it is standardized.
It is de
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> This makes the gnulib 'getpass' module (not the 'getpass-gnu' module)
>> rather difficult to use: how do you know whether to de-allocate the
>> returned string or not? It depends on whether the system function or
>> the gnulib r
Simon Josefsson wrote:
> This makes the gnulib 'getpass' module (not the 'getpass-gnu' module)
> rather difficult to use: how do you know whether to de-allocate the
> returned string or not? It depends on whether the system function or
> the gnulib replacement was used.
Good point.
> Another way
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I noticed that a significant difference between other getpass
> implementations and glibc/gnulib's is that the latter allocate the
> output buffer.
Sorry, that is false: I just now noticed the 'static' modified in the
getpass.c code This makes it
I noticed that a significant difference between other getpass
implementations and glibc/gnulib's is that the latter allocate the
output buffer.
This makes the gnulib 'getpass' module (not the 'getpass-gnu' module)
rather difficult to use: how do you know whether to de-allocate the
returned string
13 matches
Mail list logo
