Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zlib: be strict about what strategies are accepted #10934

Closed
wants to merge 1 commit into from

Conversation

Trott
Copy link
Member

@Trott Trott commented Jan 21, 2017

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), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

zlib

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 Trott added semver-major PRs that contain breaking changes and should be released in the next major version. zlib Issues and PRs related to the zlib subsystem. labels Jan 21, 2017
throw new Error('Invalid strategy: ' + opts.strategy);
}
}
if (opts.strategy && !(strategies.includes(opts.strategy)))
Copy link
Member

@lpinca lpinca Jan 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: why !(strategies.includes(opts.strategy)) instead of just !strategies.includes(opts.strategy)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Buffer means checking that !foo is an instance of Buffer which is not at all the same as foo not an instances of Buffer....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem, keep it the way it is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

works for me

@Trott Trott mentioned this pull request Jan 23, 2017
3 tasks
@Trott
Copy link
Member Author

Trott commented Jan 25, 2017

Trott added a commit to Trott/io.js that referenced this pull request Jan 25, 2017
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 <[email protected]>
Reviewed-By: Michaël Zasso <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
@Trott
Copy link
Member Author

Trott commented Jan 25, 2017

Landed in dd928b0

@Trott Trott closed this Jan 25, 2017
@jasnell jasnell mentioned this pull request Apr 4, 2017
@Trott Trott deleted the zlib-strat2 branch October 14, 2021 13:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver-major PRs that contain breaking changes and should be released in the next major version. zlib Issues and PRs related to the zlib subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

zlib strategy constants not strictly enforced
6 participants