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

test: refactor test-https-truncate #10225

Closed
wants to merge 1 commit into from

Conversation

Trott
Copy link
Member

@Trott Trott commented Dec 11, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

test https

Description of change
  • use common.mustCall() where appropriate
  • Buffer.allocUnsafe() -> Buffer.alloc()
  • do crypto check before loading any additional modules
  • specify 1ms duration for setTimeout()

* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`
@Trott Trott added https Issues or PRs related to the https subsystem. test Issues and PRs related to the tests. labels Dec 11, 2016
@nodejs-github-bot nodejs-github-bot added dont-land-on-v7.x test Issues and PRs related to the tests. labels Dec 11, 2016
@Trott
Copy link
Member Author

Trott commented Dec 11, 2016

Copy link
Member

@benjamingr benjamingr left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -14,7 +15,7 @@ const key = fs.readFileSync(common.fixturesDir + '/keys/agent1-key.pem');
const cert = fs.readFileSync(common.fixturesDir + '/keys/agent1-cert.pem');

// number of bytes discovered empirically to trigger the bug
const data = Buffer.allocUnsafe(1024 * 32 + 1);
const data = Buffer.alloc(1024 * 32 + 1);
Copy link
Member

Choose a reason for hiding this comment

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

May I ask why alloc is preferred over allocUnsafe in a test?

Copy link
Member Author

@Trott Trott Dec 12, 2016

Choose a reason for hiding this comment

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

May I ask why alloc is preferred over allocUnsafe in a test?

I don't feel strongly about it, but here's the thinking:

  • If we use Buffer.alloc(), then we get a buffer with predictable contents. While the contents don't play a role in the test here, all things being equal, I prefer having repeatable, predictable tests over tests with unpredictable inputs involved (unless, of course, the purpose is to do something like fuzz testing).

  • This is not performance-critical code, so the (small, in this case) performance hit of zero-filling is not a concern.

  • The very name of Buffer.allocUnsafe() seems to suggest "Don't use it unless you need to and know what you're doing." We don't need it here, so...

Again, I don't feel particularly strongly about it, but it does seem to me that if we can use either alloc() or allocUnsafe() in a test without any real difference, then we should default to alloc(). (The situation is different in lib where it stands to reason that tiny performance hits can add up to significant performance issues for some use cases. I'm only talking about test here.)

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I'm fine with that, was just curious.

@lance
Copy link
Member

lance commented Dec 12, 2016

Landed in 8bad37a

@lance lance closed this Dec 12, 2016
lance pushed a commit that referenced this pull request Dec 12, 2016
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: #10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 18, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: nodejs#10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 19, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: nodejs#10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 24, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: nodejs#10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Jan 27, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: nodejs#10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@italoacasas italoacasas mentioned this pull request Jan 29, 2017
MylesBorins pushed a commit that referenced this pull request Mar 7, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: #10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 7, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: #10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: #10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
MylesBorins pushed a commit that referenced this pull request Mar 9, 2017
* use common.mustCall() where appropriate
* Buffer.allocUnsafe() -> Buffer.alloc()
* do crypto check before loading any additional modules
* specify 1ms duration for `setTimeout()`

PR-URL: #10225
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Mar 9, 2017
@Trott Trott deleted the refactor-truncate branch January 13, 2022 22:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
https Issues or PRs related to the https subsystem. test Issues and PRs related to the tests.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants