You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 21, 2026. It is now read-only.
this is not about any wrong behaviour I would have noticed, but something that puzzled me when reading the code.
At https://github.com/go-audio/wav/blob/v1.1.0/decoder.go#L318 , since we're not returning nil, and we are returning m, and not explicitly 0, I assume that the call to Read above, could have partially succeeded until we hit the EOF, right?
If not, and if m is always 0 here, then you can forget about this issue (except I would explicitly return 0 to make it clear).
But if yes, then it means there possibly indeed is some data in tmpBuf at this point, right? And if yes, then I'm wondering why we are not copying the data from tmpBuf into buf.Data ? Shouldn't buf.Data always be populated as soon as m >= 0 is returned?
Hey,
this is not about any wrong behaviour I would have noticed, but something that puzzled me when reading the code.
At https://github.com/go-audio/wav/blob/v1.1.0/decoder.go#L318 , since we're not returning nil, and we are returning m, and not explicitly 0, I assume that the call to Read above, could have partially succeeded until we hit the EOF, right?
If not, and if m is always 0 here, then you can forget about this issue (except I would explicitly return 0 to make it clear).
But if yes, then it means there possibly indeed is some data in tmpBuf at this point, right? And if yes, then I'm wondering why we are not copying the data from tmpBuf into buf.Data ? Shouldn't buf.Data always be populated as soon as m >= 0 is returned?