zlib: be strict about what strategies are accepted#10934
zlib: be strict about what strategies are accepted#10934Trott wants to merge 1 commit intonodejs:masterfrom
Conversation
Currently, strategy constants are integers but Node.js will accept string versions of those integers. Users should be using the provided zlib constants and not hardcoding numbers, strings, or anything else. As such, Node.js should be strict about accepting only exactly those values that are in the provided zlib constants. Fixes: nodejs#10932
Trott
added
semver-major
| throw new Error('Invalid strategy: ' + opts.strategy); | ||
| } | ||
| } | ||
| if (opts.strategy && !(strategies.includes(opts.strategy))) |
There was a problem hiding this comment.
Nit: why !(strategies.includes(opts.strategy)) instead of just !strategies.includes(opts.strategy)?
There was a problem hiding this comment.
Happy to remove it if it's bothersome, but the reason I (sometimes) use the parentheses like that are:
- clarity of intention
- helps out people who may not know operator precedence
- force of habit from
!(foo instanceof Buffer)being the correct way to do things because!foo instanceof Buffermeans checking that!foois an instance ofBufferwhich is not at all the same asfoo not an instances of Buffer....
There was a problem hiding this comment.
No problem, keep it the way it is.
There was a problem hiding this comment.
A range check may be faster than includes ...e.g.
if (opts.strategy >= constants.Z_DEFAULT_STRATEGY &&
opt.strategy <= constants.Z_FIXED) { ... }
A bit more work to maintain if these values ever change but it avoids the linear scan of the array that includes() requires.
There was a problem hiding this comment.
Given the overhead of actually compressing and/or decompressing, I suspect such a change for performance purposes in the constructor would be something that would be impossible to measure in any real-world scenario. Counter-examples more than welcome. Barring that, I would prefer the code be clear and not be dependent on unspoken assumptions about constants defined externally.
Currently, strategy constants are integers but Node.js will accept string versions of those integers. Users should be using the provided zlib constants and not hardcoding numbers, strings, or anything else. As such, Node.js should be strict about accepting only exactly those values that are in the provided zlib constants. PR-URL: nodejs#10934 Fixes: nodejs#10932 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
|
Landed in dd928b0 |
6 participants
Currently, strategy constants are integers but Node.js will accept
string versions of those integers. Users should be using the provided
zlib constants and not hardcoding numbers, strings, or anything else. As
such, Node.js should be strict about accepting only exactly those values
that are in the provided zlib constants.
Fixes: #10932
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
zlib