Re: lseek always include windows.h?

[Eric Blake]

Simon Josefsson <simon <at> josefsson.org> writes:

> > Yes, because of the GNU philosophy of avoiding arbitrary limits (including 
a 
> >>2gb file that getpass happens to be reading from).
> 
> I didn't follow the discussions regarding fseek*, but will using 'fseek
> (out, 0, SEEK_CUR);' instead of fseek really break anything?

Yes.  If getpass.c is compiled on a platform that lacks /dev/tty support and 
which has 32-bit long but 64-bit off_t, and is given stdout as a seekable file 
bigger than 2gb, then the fseek is required to fail with EOVERFLOW while fseeko 
will correctly reposition the file.  On platforms with /dev/tty support, plain 
fseek should be okay (since ttys are non-seekable, both fseek and fseeko are 
likely no-ops that fail with ESPIPE, although POSIX leaves the behavior of 
fseek on a tty undefined).

> Btw, the error value from fseeko is not checked.  Would it make sense to
> avoid printing \n if fseeko failed?

On platforms with /dev/tty support, it is likely that fseek[o] always fails 
because ttys are not seekable.  So checking for fseek[o] error isn't really 
going to do the getpass module any good.  Rather, the point of the fseeko is 
the side effect of safely switching from reading to writing on an updateable 
stream, which should happen even if the fseeko failed.

>  Printing the \n when fseeko may
> lead to revealing the password, if I understand the comment correctly
> (and if the comment is in fact correct).

I don't think this is an issue in the getpass code.

> 
> /Simon
> 
> 

-- 
Eric Blake