commit-classpath
[Top][All Lists]
Advanced

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

[bug #5558] BufferedReader incorrect EOF detection.


From: nobody
Subject: [bug #5558] BufferedReader incorrect EOF detection.
Date: Wed, 24 Sep 2003 23:14:25 -0400
User-agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)

=================== BUG #5558: FULL BUG SNAPSHOT ===================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5558&group_id=85

Submitted by: mlbrereton              Project: classpath                    
Submitted on: Thu 09/25/2003 at 03:14
Severity:  5 - Major                  Resolution:  None                     
Assigned to:  None                    Status:  Open                         
Platform Version:  None               

Summary:  BufferedReader incorrect EOF detection.

Original Submission:  There is the potential for java.io.BufferedReader to 
incorrectly detect an EOF condition early if:



1. A readLine() is called and the internal buffer contains a 'r' as its last 
character.



2. The in.read() method call in the fill() method returns a single character 
which happens to be 'n'.



If these two occur the fill() method returns a zero value and the read() method 
incorrectly interprets it as an EOF indication.



==================================



The java.io.BufferedReader method int read() contains the line:

        if (pos >= limit && fill () <= 0)

                return -1;



The fill() method re-fills the internal buffer, but a bug occurs when pos > 
limit. According to the source code, if a 'r' is the last character in the 
current buffer when a readLine() is called, the line is returned and pos is set 
to limit+1 as a special case to indicate to fill() that if a 'n' is read next, 
it should be ignored. 



        if (buffer[i] == 'r')

          if (pos == limit || buffer[pos] == 'n')

            pos++;



The fill() method then duly ignores a following 'n' with the lines:



    int count = in.read(buffer, limit, buffer.length - limit);

    if (count > 0)

      limit += count;



    if (retAtEndOfBuffer && buffer[pos] == 'n')

      {

        --count;

        if (markPos == pos)

          ++markPos;

        ++pos;

      }



    return count;



Now take the case where the in.read() call in the above lines returns a single 
character, a 'n', after a 'r' was read at the end of the buffer in the last 
readLine(). If this happens the --count line gets executed, and count gets 
decremented to zero. The method then returns a value of zero and this causes 
the read() method to return -1, indicating an incorrect EOF condition.



The bug is corrected in the read() method by using these lines instead of the 
original:



        while (pos >= limit){

                int f = fill();

                if (f < 0) return -1;

                if (f > 0) break;

        }



The bug can be demonstrated by implementing a Reader that always reads a single 
character at a time, and wrapping that up in a BufferedReader. e.g.:



        BufferedReader bbr = new BufferedReader(

                new Reader(){

                        String toGo = "Line 1rnLine 2rnLine 3";

                        int did = 0;

                        public int read(char[] buff,int offset,int count){

                                if (did < toGo.length()){

                                        buff[offset] = toGo.charAt(did++);

                                        return 1;

                                }

                                return -1;

                        }

                        public void close(){did = toGo.length();}

                }

        );

        while(true){

                String line = bbr.readLine();

                if (line == null) break;

                System.out.println(line);

        }

        System.out.println("-- Done! --- ");

        bbr.close();







No Followups Have Been Posted


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=5558&group_id=85

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]