-
Notifications
You must be signed in to change notification settings - Fork 30.7k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
zlib: fix decompression of empty data streams #17042
Conversation
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with a nit.
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alloc()
has what is essentially a fast path for 0
, allocUnsafe()
doesn’t.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very interesting. thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Landed in 01f853c |
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 <info@bnoordhuis.nl> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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 <info@bnoordhuis.nl> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
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