PR-URL: https://github.com/nodejs/node/pull/36952
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
`kNormal` has been the implicit default for a while now (since V8 7.6).
Refs: e0d7f81699
PR-URL: https://github.com/nodejs/node/pull/34248
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
"utf-16LE" was parsed "UNKNOWN", this fixes to "UCS2"
"utf-buffer" was parsed "BUFFER", this fixes to "UNKNOWN"
"utf-16leNOT" was parsed "UCS2", this fixes to "UNKNOWN"
PR-URL: https://github.com/nodejs/node/pull/33957
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently, there are a number of compiler warnings generated when
building the addons on Linux, for example:
make[1]: Entering directory '/node/test/addons/zlib-binding/build'
CXX(target) Release/obj.target/binding/binding.o
SOLINK_MODULE(target) Release/obj.target/binding.node
COPY Release/binding.node
make[1]: Leaving directory '/node/test/addons/zlib-binding/build'
In file included from ../binding.cc:1:
/node/src/node.h:515:51: warning:
cast between incompatible function types from
'void (*)(v8::Local<v8::Object>,
v8::Local<v8::Value>,
v8::Local<v8::Context>)' to
'node::addon_context_register_func' {aka
'void (*)(v8::Local<v8::Object>,
v8::Local<v8::Value>,
v8::Local<v8::Context>,
void*)'} [-Wcast-function-type]
(node::addon_context_register_func) (regfunc), \
^
/node/src/node.h:533:3:
note: in expansion of macro 'NODE_MODULE_CONTEXT_AWARE_X'
NODE_MODULE_CONTEXT_AWARE_X(modname, regfunc, NULL, 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
../binding.cc:58:1:
note: in expansion of macro 'NODE_MODULE_CONTEXT_AWARE'
NODE_MODULE_CONTEXT_AWARE(NODE_GYP_MODULE_NAME, Initialize)
^~~~~~~~~~~~~~~~~~~~~~~~~
This commit adds the flag -Wno-cast-function-type to suppress these
warnings. With this change the warnings are not displayed anymore and
the output matches that of osx when running
'make -j8 test/addons/.buildstamp'.
PR-URL: https://github.com/nodejs/node/pull/25663
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Currently the nm_modname does not match the file name of the resulting
module. In fact, the nm_modname is pretty arbitrary. This seeks to
introduce some consistency into the nm_modname property by having the
name of the module appear in exactly one place: the "target_name"
property of the gyp target that builds the module.
PR-URL: https://github.com/nodejs/node/pull/15209
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Having semicolons there runs counter to our documentation and illicits
warnings in pedantic mode. This removes semicolons from after uses of
NODE_MODULE and NODE_MODULE_CONTEXT_AWARE_BUILTIN.
PR-URL: https://github.com/nodejs/node/pull/12919
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
The doc/api/addons.md document contains examples of Addon
Initialization functions that take a parameter named exports.
This also matches the name used in node.cc when calling:
mp->nm_register_func(exports, module, mp->nm_priv);
Currently, a number of the tests name this same parameter target. This
commit renames target to exports for consistency.
PR-URL: https://github.com/nodejs/node/pull/9135
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Currently when running configure with the --debug option in combination
with the tests (./configure --debug && make -j8 test) there are a few
addon tests that fail with error messages similar to this:
=== release test ===
Path: addons/load-long-path/test
fs.js:558
return binding.open(pathModule._makeLong(path), stringToFlags(flags),
mode);
^
Error: ENOENT: no such file or directory, open
'/nodejs/node/test/addons/load-long-path/build/Release/binding.node'
at Object.fs.openSync (fs.js:558:18)
at Object.fs.readFileSync (fs.js:468:33)
at Object.<anonymous>
(/nodejs/node/test/addons/load-long-path/test.js:28:19)
at Module._compile (module.js:560:32)
at Object.Module._extensions..js (module.js:569:10)
at Module.load (module.js:477:32)
at tryModuleLoad (module.js:436:12)
at Function.Module._load (module.js:428:3)
at Module.runMain (module.js:594:10)
at run (bootstrap_node.js:382:7)
Command: out/Release/node
/nodejs/node/test/addons/load-long-path/test.js
This commit allows for the tests to pass even if the configured build
type is of type debug.
PR-URL: https://github.com/nodejs/node/pull/8836
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Ilkka Myller <ilkka.myller@nodefield.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/7947
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Make BINARY an alias for LATIN1 rather than a distinct enum value.
PR-URL: https://github.com/nodejs/node/pull/7284
Refs: https://github.com/nodejs/node/pull/7262
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
A missing 'break' statement unintentionally allowed "linary"
and "luffer" as alternatives for "binary" and "buffer".
Regression introduced in commit 54cc7212 ("buffer: introduce latin1
encoding term".)
PR-URL: https://github.com/nodejs/node/pull/7262
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>