views:

1498

answers:

2

Hello everyone,

Any ideas why in the below sample, we need to add 100 (buffer.Length + 100)? buffer.Length should be the same as decompressed buffer length, so no need to add 100 more. :-)

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

thanks in advance, George

+3  A: 

I don't know why they're doing that, but it's not a great example in general - for instance, they're using explicit calls to Close (not in a finally block) on the FileStream instead of using a using statement, and also assuming that a single call to Read will read the whole of a file. Heck, even reading the whole file into a buffer is a bad idea - it would be better to copy a chunk at a time straight into the DeflateStream.

These things suggest to me that it's not worth worrying about this specific odd bit of code (the extra 100 bytes) within that example. Certainly don't regard it as "best practice".

MSDN examples are usually better than this - although there are plenty of other odd ones.

EDIT: Having reread the code and CodeMelt's answer, it does indeed need the extra 100 bytes - but only because ReadAllBytesFromStream is implemented so badly. Here's a better implementation, which always asks the stream to fill the rest of the buffer:

public static int ReadAllBytesFromStream(Stream stream, byte[] buffer) 
{
    int offset = 0;
    int bytesRead;
    while ((bytesRead = stream.Read(buffer, offset, 
                                    buffer.Length-offset)) > 0) 
    {
        offset += bytesRead;
    }
    return offset;
}

(Note that there was no need for both offset and totalCount as they always had the same value.)

Jon Skeet
I fully agree with you about your points of close and reading all bytes altogether. I just want to confirm the decompression buffer is the same length of the original buffer, no need in practices to allocate 100 bytes or something more?
George2
In what situations will previous implementation code has issue? Could you show me an example please?
George2
It will throw an ArgumentException when it gets near the end of the array (if you don't make the array 100 bytes larger than necessary) because the "count" parameter was fixed at 100.
Jon Skeet
Hi Jon Skeet, what kinds of file will cause such type exception? What size? I am interested to make one test case and make my hands dirty.
George2
The exception will only be thrown if you take out the extra 100 bytes but *don't* fix the ReadAllBytesFromStream method. I think in that case *any* file would give the exception.
Jon Skeet
+2  A: 

It prevents stream.Read(buffer, offset, 100) from going over its length within the following method because the stream keeps reading until it reads nothing.

public static int ReadAllBytesFromStream(Stream stream, byte[] buffer) 
{
// Use this method is used to read all bytes from a stream.
int offset = 0;
int totalCount = 0;
    while (true) 
    {
    // even it reads to the end, but it will still read the next
    // 100 bytes to see if anything has been read.
    int bytesRead = stream.Read(buffer, offset, 100); 
        if ( bytesRead == 0) 
        {
        break; 
        }
offset += bytesRead;
totalCount += bytesRead; 
    }
return totalCount;
}
codemeit
Confused. :-( What do you mean "going over its length" and in what scenario will it "going over its length"? If result length is the same as original input length, it is fine and no need to allocate 100 bytes more.
George2
ReadAllBytesFromStream does not check the length of buffer, the extra 100 bytes there is to give a room for stream.Read(buffer, offset, 100); to return 0;
codemeit
But I think there is no need to make an additional room? What is the impact if no such additional room? This pattern of code is really strange.
George2
@George2: Yes, it's basically just because of the poor implementation of ReadAllBytesFromStream. See my updated answer for a better implementation.
Jon Skeet
In what situations will previous implementation code has issue? Could you show me an example please?
George2