[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: getline() doesn't seem to work?
From:       hjl () lucon ! org (H ! J !  Lu)
Date:       1998-01-31 6:16:11
[Download RAW message or body]

> 
> > > I don't know if this is a bug in getline, or just a bug in my
> > > understanding of getline.  When I have the following program just
> > > reading from my terminal, I have to hit control-D twice before the
> > > loop exits.  It appears that the first time I hit control-D, getline
> 
> > How is this patch?
> > Fri Jan 30 07:47:57 1998  H.J. Lu  (hjl@gnu.org)
> >	* isgetline.cc (istream::getline, istream::get): Call
> >	* isgetline.cc (istream::getline, istream::get): Call
> >	streambuf::in_avail () to check EOF when _IO_getline ()
> >	returns 0.
> 
> This is wrong.  istream::getline should not call streambuf::in_avail.
> istream::getline should just be a more convienient and efficient
> interface than you could write yourself as a loop using sgetc/sbumpc.
> It should not require the more magic streambuf::in_avail.
> 
> Furthermore, this solution is not consistent.  fgets and gets do not
> check for availability.  Instead they check if fp->_IO_file_flags

The reason of fgets and gets don't check for availability is
they don't have to check the next char. They can just return
whatever _IO_getline gets even for EOF. But that is not true
for istream::getline nor istream::getline.

> has _IO_ERR_SEEN set.  istream::getline should work similarly,
> except use _IO_EOF_SEEN.

I am not sure if that will work sincce _IO_EOF_SEEN may be set
by the previous read. It may happen on pipe or socket. You have
to make sure _IO_EOF_SEEN is set in this read.

> 
> I thought about changing the interface of _IO_getline so it returns
> -1 on EOF.  (The return type should then be changed from _IO_size_t
> to _IO_ssize_t.)  That would make it easy to test if EOF was seen.
> However, that would not solve the problem of a partial line line
> followed by EOF (and no delimiter).  The code would still try to read
> the delimiter - even after EOF is seen.   While this is presumably
> harmless except on terminals, and a terminal would not return
> a partial line followed by EOF - still, we should avoid reading an
> extra character after EOF has been seen.  So I propose something like
> the following.  (Note I have not looked at istream::get.)
> 

istream::get has the same problem.


H.J.

[prev in list] [next in list] [prev in thread] [next in thread]