zlib: fix decompression of empty data streams #17042
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
add4b0a made the assumption that compressed data would never lead to an empty decompressed stream. Fix that by explicitly checking the number of read bytes. Fixes: nodejs#17041 Refs: nodejs#13322
addaleax
added
dont-land-on-v6.x
zlib
bnoordhuis
approved these changes
Nov 15, 2017
lpinca
approved these changes
Nov 15, 2017
cjihrig
approved these changes
Nov 15, 2017
evanlucas
approved these changes
Nov 16, 2017
mcollina
approved these changes
Nov 16, 2017
| @@ -95,6 +95,8 @@ function zlibBufferOnEnd() { | |||
| var err; | |||
| if (this.nread >= kMaxLength) { | |||
| err = new errors.RangeError('ERR_BUFFER_TOO_LARGE'); | |||
| } else if (this.nread === 0) { | |||
| buf = Buffer.alloc(0); | |||
There was a problem hiding this comment.
I don't know if there is any performance penalty to use Buffer.alloc(0) vs Buffer.allocUnsafe(0). However, as it's 0 I would use allocUnsafe.
There was a problem hiding this comment.
alloc() has what is essentially a fast path for 0, allocUnsafe() doesn’t.
There was a problem hiding this comment.
This is very interesting. thanks!
There was a problem hiding this comment.
I mean, I don’t think it’s that way on purpose. :) It just happens to align nicely with how we can use basically new Uint8Array(n) for the Buffer.alloc() fast path, whereas Buffer.allocUnsafe() needs a bit of setup.
jasnell
approved these changes
Nov 16, 2017
|
Landed in 01f853c |
addaleax
added a commit
that referenced
this pull request
Nov 18, 2017
add4b0a made the assumption that compressed data would never lead to an empty decompressed stream. Fix that by explicitly checking the number of read bytes. PR-URL: #17042 Fixes: #17041 Refs: #13322 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
MylesBorins
pushed a commit
that referenced
this pull request
Dec 12, 2017
add4b0a made the assumption that compressed data would never lead to an empty decompressed stream. Fix that by explicitly checking the number of read bytes. PR-URL: #17042 Fixes: #17041 Refs: #13322 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: James M Snell <[email protected]>
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
add4b0a made the assumption that compressed data
would never lead to an empty decompressed stream.
Fix that by explicitly checking the number of read bytes.
Fixes: #17041
Refs: #13322
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
zlib