Main Site Documentation

Anomolous behaviour od StreamReader


#1

I tried to use the StreamReader class and I have discovered what I believe is a small anomoly


  using ( StreamReader reader = new StreamReader( name ) )
  {
      // it seems micro.NET behaves slightly differently to .NET
      // this is required otherwise EndOfStream is true immediatly
      reader.BaseStream.Seek( 0, SeekOrigin.Begin );

      while ( reader.EndOfStream == false )
      {
          string line = reader.ReadLine();
          Debug.Print( line );
      }
  }


#2

actually that didnt work (but this does), it seems that EndOfStream isnt set until you read a line


  using ( StreamReader reader = new StreamReader( name ) )
  {
      do
      {
          string line = reader.ReadLine();
          Debug.Print( line );
      }
      while ( reader.EndOfStream == false )
  }


#3

It is possible.

I prefer to check if ReadLine returns null, though. Works great.


            using (StreamReader sr = new StreamReader(name)) 
            {
                string line;
                // Read and display lines from the file until the end of 
                // the file is reached.
                while ((line = sr.ReadLine()) != null) 
                {
                    Debug.Print(line);
                }
            }


#4

Im sure I tried that, ill try again


#5

My SR.Readline() return “”, not null. Will check again, but wonder if we using same MF?


#6

Official MF (according to the documentation) returns null if end of stream is reached :wink: .

http://msdn.microsoft.com/en-us/library/ee435716.aspx

But it looks like lots of people have some issues with ReadLine, so there may be a bug. I have to try it later.


#7

I agree the docs say Null. But MF ReadLine is not currently respecting the docs. It returns empty string. If you test for only null as in sample code, the loop will spin. Method below adds a test at the end to return the null:

public static string ReadLineEx(StreamReader sr)
{
    int newChar = 0;
    int bufLen = 512; // NOTE: the smaller buffer size.
    char[] readLineBuff = new char[bufLen];
    int growSize = 512;
    int curPos = 0;
    while ((newChar = sr.Read()) != -1)
    {
        if (curPos == bufLen)
        {
            if ((bufLen + growSize) > 0xffff)
            {
                throw new Exception();
            }
            char[] tempBuf = new char[bufLen + growSize];
            Array.Copy(readLineBuff, 0, tempBuf, 0, bufLen);
            readLineBuff = tempBuf;
            bufLen += growSize;
        }
        readLineBuff[curPos] = (char)newChar;
        if (readLineBuff[curPos] == '\n')
        {
            return new string(readLineBuff, 0, curPos);
        }
        if (readLineBuff[curPos] == '\r')
        {
            if (sr.Peek() == 10)
            {
                sr.Read();
            }
            return new string(readLineBuff, 0, curPos);
        }
        curPos++;
    }
            
    if (curPos == 0) return null; // Null fix.
    return new string(readLineBuff, 0, curPos);
}

#8

I have looked at the Reflector too and it does look like a bug in MF. Your fix looks good to me.
I wonder if MS is aware of that, may be GHI folks can channel it through to the right people.


#9

You can post info about the issue directly to MSFT at http://www.netmf.com/Discussion/Forums.aspx in the bug reports forum. They seem to be really good about responding to user-reported issues.


#10

Oh I am sure there is a place to report it and it most likely has been reported already. It might make the fix come out faster when it is reported by a partner as well.


#11

I thought GHI could fix these now because the source is Open and they can rebuild the firmware? Wasn’t that the point of making it open? tia

[edit] I posted bug to CodePlex: http://netmf.codeplex.com/workitem/list/basic


#12

Yes, but that will be a maintainability nightmare. The bug is in MF code. If it is not fixed by MS than with each new release of Micro Framework from Microsoft, GHI (and other providers) has to go to the source and apply all their “custom” patches.
MF is maintained by Microsoft and all bugs in their code should be fixed by them so it will be available to all providers.


#13

"Yes, but that will be a maintainability nightmare. The bug is in MF code. If it is not fixed by MS than with each new release of Micro Framework from Microsoft, GHI (and other providers) has to go to the source and apply all their “custom” patches. "

Thank you Architect. This makes my point about OS. Good in theory, but does not work in production. I think I saw the Arduno people did change their build, but I agree with you as change control and integration testing just explode.


#14

Correct but Microsoft works with partners on solving any bugs. GHI (and I assume others too) passes on a list of bug to Microsoft to solve in the base.
This process became easier that now the porting kit on codeplex. See this for example on bugs http://netmf.codeplex.com/workitem/list/basic


#15

Makes total sense. That is the way it should be.


#16

I have just added my vote for that bug:

http://netmf.codeplex.com/workitem/480