Answered by:
When does IInputStream.ReadAsync return a different buffer?

Question
-
In the offline documentation, ReadAsync is documented as:
buffer: The buffer into which the asynchronous read operation places the bytes that are read
count: The number of bytes that is less than or equal to the CapacityHowever, in the online documentation, it now says:
(http://msdn.microsoft.com/en-us/library/windows.storage.streams.iinputstream.readasync.aspx)
buffer: A buffer that may be used to return the bytes that are read. The return value contains the buffer that holds the results.
and includes an extra remarks section:
Remarks
Always read data from the buffer returned in the IAsyncOperationWithProgress(IBuffer, UInt32). Don't assume that the input buffer contains the data. Depending on the implementation, the data that's read might be placed into the input buffer, or it might be returned in a different buffer.
So having allocated all of that memory to read, and created a buffer, the function can just return something else, and make me copy it. This is so inefficient for an edge case, as it appears that the buffer returned is the one passed in, but now I need to check, or worse, copy the bytes.
Is checking the value of the return IBuffer is equal to the one passed in sufficient to know that a copy isn't necessary, or is some other checking necessary?
Anthony Wieser | Wieser Software Ltd | www.wieser-software.com
Tuesday, November 25, 2014 6:15 AM
Answers
-
I got this reply last night:
"Yes, if the IBuffer you get back is the same one that went in, then clearly it’s the same object identity and so you know the app-provided buffer is the one that was used.
As the documentation mentions the buffers can’t be assumed to always be the same though."
Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.
NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.- Marked as answer by Anthony WieserMicrosoft employee Wednesday, December 17, 2014 7:29 AM
Tuesday, December 16, 2014 1:05 PMModerator
All replies
-
Hi Anthony - I'll pass this question to our internal folks for an answer. Feel free to bump if you don't hear back from me by Monday (holidays here in the US).
Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.
NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.- Marked as answer by Jamles HezModerator Sunday, December 7, 2014 2:21 PM
- Unmarked as answer by Jamles HezModerator Sunday, December 7, 2014 2:21 PM
- Proposed as answer by Jamles HezModerator Sunday, December 7, 2014 2:21 PM
- Unproposed as answer by Anthony WieserMicrosoft employee Sunday, December 7, 2014 5:33 PM
Tuesday, November 25, 2014 8:51 PMModerator -
Sunday, December 7, 2014 5:34 PM
-
I'm checking with our folks again. I've been out of the office for a while.
Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.
NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.Monday, December 15, 2014 5:10 PMModerator -
I got this reply last night:
"Yes, if the IBuffer you get back is the same one that went in, then clearly it’s the same object identity and so you know the app-provided buffer is the one that was used.
As the documentation mentions the buffers can’t be assumed to always be the same though."
Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.
NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.- Marked as answer by Anthony WieserMicrosoft employee Wednesday, December 17, 2014 7:29 AM
Tuesday, December 16, 2014 1:05 PMModerator -
Thanks for the reply.
Any ideas when (i.e., in what circumstances) the supplied buffer might not be the buffer used?
Given the documentation appears to only recently have been added to include this, this is a potential breaking change for every app out there.
Anthony Wieser | Wieser Software Ltd | www.wieser-software.com
Tuesday, December 16, 2014 5:05 PM -
"It’s an implementation decision by the stream. This might be a recent documentation clarification but it’s not a breaking change; the behavior has always been this way and the IBuffer is returned by the async operation for this reason."
Matt Small - Microsoft Escalation Engineer - Forum Moderator
If my reply answers your question, please mark this post as answered.
NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.Tuesday, December 16, 2014 7:13 PMModerator