<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/node-new.git/test/parallel/test-child-process-execsync-maxbuf.js, branch Remove-Python-3-tests</title>
<subtitle>github.com: nodejs/node.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/'/>
<entry>
<title>lib: correct error.errno to always be numeric</title>
<updated>2019-06-17T02:18:09+00:00</updated>
<author>
<name>Joyee Cheung</name>
<email>joyeec9h3@gmail.com</email>
</author>
<published>2019-06-09T13:04:51+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/commit/?id=1432065e9dc77218507f328b63cb7f5d279dd6e9'/>
<id>1432065e9dc77218507f328b63cb7f5d279dd6e9</id>
<content type='text'>
Historically `error.errno` of system errors thrown by Node.js
can sometimes be the same as `err.code`, which are string
representations of the error numbers. This is useless and incorrect,
and results in an information loss for users since then they
will have to resort to something like
`process.binding('uv'[`UV_${errno}`])` to get to the numeric
error codes.

This patch corrects this behavior by always setting `error.errno`
to be negative numbers. For fabricated errors like `ENOTFOUND`,
`error.errno` is now undefined since there is no numeric equivalent
for them anyway. For c-ares errors, `error.errno` is now undefined
because the numeric representations (negated) can be in conflict
with libuv error codes - this is fine since numeric codes was
not available for c-ares errors anyway.

Users can use the public API `util.getSystemErrorName(errno)`
to retrieve string codes for these numbers.

PR-URL: https://github.com/nodejs/node/pull/28140
Reviewed-By: James M Snell &lt;jasnell@gmail.com&gt;
Reviewed-By: Colin Ihrig &lt;cjihrig@gmail.com&gt;
Reviewed-By: Rich Trott &lt;rtrott@gmail.com&gt;
Reviewed-By: Trivikram Kamat &lt;trivikr.dev@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Historically `error.errno` of system errors thrown by Node.js
can sometimes be the same as `err.code`, which are string
representations of the error numbers. This is useless and incorrect,
and results in an information loss for users since then they
will have to resort to something like
`process.binding('uv'[`UV_${errno}`])` to get to the numeric
error codes.

This patch corrects this behavior by always setting `error.errno`
to be negative numbers. For fabricated errors like `ENOTFOUND`,
`error.errno` is now undefined since there is no numeric equivalent
for them anyway. For c-ares errors, `error.errno` is now undefined
because the numeric representations (negated) can be in conflict
with libuv error codes - this is fine since numeric codes was
not available for c-ares errors anyway.

Users can use the public API `util.getSystemErrorName(errno)`
to retrieve string codes for these numbers.

PR-URL: https://github.com/nodejs/node/pull/28140
Reviewed-By: James M Snell &lt;jasnell@gmail.com&gt;
Reviewed-By: Colin Ihrig &lt;cjihrig@gmail.com&gt;
Reviewed-By: Rich Trott &lt;rtrott@gmail.com&gt;
Reviewed-By: Trivikram Kamat &lt;trivikr.dev@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>child_process: change the defaults maxBuffer size</title>
<updated>2019-04-17T21:05:15+00:00</updated>
<author>
<name>kohta ito</name>
<email>kohta110@gmail.com</email>
</author>
<published>2019-04-10T18:26:58+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/commit/?id=652877e3a9eee3f863314382f64f8ac1e5b27186'/>
<id>652877e3a9eee3f863314382f64f8ac1e5b27186</id>
<content type='text'>
PR-URL: https://github.com/nodejs/node/pull/27179
Refs: https://github.com/nodejs/node/pull/23027
Reviewed-By: Ben Noordhuis &lt;info@bnoordhuis.nl&gt;
Reviewed-By: Sam Roberts &lt;vieuxtech@gmail.com&gt;
Reviewed-By: Ruben Bridgewater &lt;ruben@bridgewater.de&gt;
Reviewed-By: Michaël Zasso &lt;targos@protonmail.com&gt;
Reviewed-By: Beth Griggs &lt;Bethany.Griggs@uk.ibm.com&gt;
Reviewed-By: Michael Dawson &lt;michael_dawson@ca.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
PR-URL: https://github.com/nodejs/node/pull/27179
Refs: https://github.com/nodejs/node/pull/23027
Reviewed-By: Ben Noordhuis &lt;info@bnoordhuis.nl&gt;
Reviewed-By: Sam Roberts &lt;vieuxtech@gmail.com&gt;
Reviewed-By: Ruben Bridgewater &lt;ruben@bridgewater.de&gt;
Reviewed-By: Michaël Zasso &lt;targos@protonmail.com&gt;
Reviewed-By: Beth Griggs &lt;Bethany.Griggs@uk.ibm.com&gt;
Reviewed-By: Michael Dawson &lt;michael_dawson@ca.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>child_process: use non-infinite maxBuffer defaults</title>
<updated>2019-04-09T20:57:04+00:00</updated>
<author>
<name>kohta ito</name>
<email>kohta110@gmail.com</email>
</author>
<published>2018-09-22T18:11:21+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/commit/?id=eb8a51a35c961fe36ec78ccb4a176e7091408ba1'/>
<id>eb8a51a35c961fe36ec78ccb4a176e7091408ba1</id>
<content type='text'>
Set the default maxBuffer size to 204,800 bytes for execSync,
execFileSync, and spawnSync.

APIs that return the child output as a string should have non-infinite
defaults for maxBuffer sizes to avoid out-of-memory error conditions. A
non-infinite default used to be the documented behaviour for all
relevant APIs, but the implemented behaviour for execSync, execFileSync
and spawnSync was to have no maxBuffer limits.

PR-URL: https://github.com/nodejs/node/pull/23027
Refs: https://github.com/nodejs/node/pull/22894
Reviewed-By: Sam Roberts &lt;vieuxtech@gmail.com&gt;
Reviewed-By: Michaël Zasso &lt;targos@protonmail.com&gt;
Reviewed-By: Matteo Collina &lt;matteo.collina@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Set the default maxBuffer size to 204,800 bytes for execSync,
execFileSync, and spawnSync.

APIs that return the child output as a string should have non-infinite
defaults for maxBuffer sizes to avoid out-of-memory error conditions. A
non-infinite default used to be the documented behaviour for all
relevant APIs, but the implemented behaviour for execSync, execFileSync
and spawnSync was to have no maxBuffer limits.

PR-URL: https://github.com/nodejs/node/pull/23027
Refs: https://github.com/nodejs/node/pull/22894
Reviewed-By: Sam Roberts &lt;vieuxtech@gmail.com&gt;
Reviewed-By: Michaël Zasso &lt;targos@protonmail.com&gt;
Reviewed-By: Matteo Collina &lt;matteo.collina@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>doc: fix default maxBuffer size</title>
<updated>2019-04-04T01:32:26+00:00</updated>
<author>
<name>kohta ito</name>
<email>kohta110@gmail.com</email>
</author>
<published>2018-09-17T09:19:26+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/node-new.git/commit/?id=ceb80f415798818a059051537132bba691c68db7'/>
<id>ceb80f415798818a059051537132bba691c68db7</id>
<content type='text'>
Correctly document the default maxBuffer size for execSync,
execFileSync, and spawnSync. It is 200 * 1024, not Infinity.
Add tests to verify behaviour is as documented.

PR-URL: https://github.com/nodejs/node/pull/22894
Reviewed-By: Sam Roberts &lt;vieuxtech@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Correctly document the default maxBuffer size for execSync,
execFileSync, and spawnSync. It is 200 * 1024, not Infinity.
Add tests to verify behaviour is as documented.

PR-URL: https://github.com/nodejs/node/pull/22894
Reviewed-By: Sam Roberts &lt;vieuxtech@gmail.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
