locked
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 Capacity

    However, 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.

    Tuesday, December 16, 2014 1:05 PM
    Moderator

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.

    Tuesday, November 25, 2014 8:51 PM
    Moderator
  • any updates?


    Anthony Wieser | Wieser Software Ltd | www.wieser-software.com

    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 PM
    Moderator
  • 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.

    Tuesday, December 16, 2014 1:05 PM
    Moderator
  • 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 PM
    Moderator