Change size_t and friends to use long types.

[sunfishcode]

This, along with an accompanying emscripten-fastcomp change, change size_t from unsigned int to unsigned long, and related changes. The size of size_t is unchanged, in all configurations. As discussed in the proposed LLVM patch, the motivation for this change is to synchronize the asm.js and wasm ABIs, and to use unsigned long for size_t on wasm to make symbol names more consistent between wasm32 and wasm64.

The most visible effect of this is a change to C++ mangled names using size_t. size_t is now mangled to 'm' rather than 'j'. While mangled names aren't visible from within C++, this may affect tools which depend on mangled names.

Another visible effect is that code passing size_t values to printf with "%u", "%x", or similar now get a warning. The warning may be safely ignored, as there is no change in behavior. It can also be fixed by adding the 'z' modifier, such as "%zu", "%zx", and so on.

I looked into the possibility of adding warnings to help users who might be affected by this, but I didn't find any good place to do this. I'm open to suggestions here.

[kripken]

I'm neutral on this myself. If we do it carefully I don't object.

Main risk is people with existing compiled bitcode, that suddenly wouldn't link with other bitcode, I suspect.

[dschuff]

I think this is the right thing to do in general.
I'm not super worried about breaking bitcode compatibility (i mean, we should do a version bump and something in the breaking changes log, etc but it's a known thing). I think the mangled names thing is a more likely way that people will break, but at least the breakage will most likely be obvious (link-time error or possibly a runtime failure when trying to call a renamed function from JS). So we can do a mailing list post with the error message text and how to deal with it (update the name, use extern C linkage, etc).

As for how to help people more specifically than that, I don't really have any ideas I would consider "good" :). There are probably several ways you could wind up using mangled names; CLI export lists and JS code that just does Module['__Z3fooj'](42) seem like the most obvious. To catch the latter you'd have to put a layer to intercept all such calls, or try to add duplicate properties or fallbacks to catch attempts to call some nonexistent properties on the module object, or something like that; seems pretty ugly. And even then you don't have a sure mapping from a particular missing property to what it would have been before the change, because you don't know which (if any) arguments used to be size_t. So you'd have to e.g. try swapping all the combinations of 'j's for 'm's in the names. So it seems pretty bad all around, and maybe not worth it.

[kripken]

Yeah, I'm really just worried about people I know use bitcode libraries for third party code, like some game engine projects. They don't rebuild those constantly, so this might need a manual update step for them. But if we talk to them that should be fine. @juj knows the details there.

[juj]

This is a great change, since it will unify behavior with native Linux builds as well. In order to do this, we do want to bump version from 1.37.x to 1.38.0, and communicate the ABI incompatibility carefully at mailing lists. Btw do we embed Emscripten version information in to .o or .bc files? If so, we could do a specific check and warn in Emscripten >=1.38.0 if it's loading compiled code from Emscripten < 1.38.0?

[kripken]

We don't embed the emscripten version in bitcode - although maybe we could use metadata for that somehow? Not sure it's worth the overhead.

I agree this warrants a bump to 1.38.0, but that means we should be very sure everything is stable, and merge to master at that point, which we have not done in a very long time - will take some effort.

[sunfishcode]

The LLVM patch, the emscripten-fastcomp-clang patch, and the emscripten patch are now all updated and in sync.

[kripken]

Do we have a plan for landing this? From the discussion above, it sounds like we should merge to master first. Also we should probably wait on @juj's impending LLVM merge.

[juj]

Do we have a plan for landing this? From the discussion above, it sounds like we should merge to master first. Also we should probably wait on @juj's impending LLVM merge.

The LLVM merge happened and was tagged. I think we should work to merge to master next, and then to merge this and bump to 1.38.0.

[sunfishcode]

I've now rebased this against incoming.

The CI tests are failing because this PR depends on the accompanying emscripten-fastcomp and emscripten-fastcomp-clang PRs, but the tests pass for me locally when I put all of them together.

For reference, the corresponding LLVM patch for the WebAssembly target is here.

Is there anything else that needs doing here?

[kripken]

Just to be sure, which tests did you run? If you ran ./tests/runner.py (asm.js tests - we should add a proper name for that), and also ./tests/runner.py binaryen*, other, browser, and sanity, we should be good. If so, the 3 PRs sound good to land.

With their landing, please also push a 1.39.0 tag to the 3 emscripten repos and also to binaryen (tagging whatever is latest master there). We should also post to the mailing list to give people a heads up at that time.

[sunfishcode]

Ah, it seems I was only running asm.js tests. When I run a binaryen test, I get lots of errors like this:

$ tests/runner.py binaryen2.test_zero_multiplication
WARNING:./tests/runner.py:use EM_ALL_ENGINES=1 in the env to run against all JS engines, which is slower but provides more coverage
Test suites:
['test_core']
Running test_core: (1 tests)
test_zero_multiplication (test_core.binaryen2) ... (checking sanity from test runner)
WARNING:root:did not see a source tree above or next to the LLVM root directory (guessing based on directory of /Projects/build/bin/llc), could not verify version numbers match
INFO:root:(Emscripten: Running sanity checks)
WARNING:root:java does not seem to exist, required for closure compiler, which is optional (define JAVA in /home/me/.emscripten if you want it)
WARNING:root:closure compiler will not be available
INFO:root:generating system library: dlmalloc.bc... (this will be cached in "/home/me/.emscripten_cache/asmjs/dlmalloc.bc" for subsequent builds)
INFO:root: - ok
INFO:root:generating system library: libc.bc... (this will be cached in "/home/me/.emscripten_cache/asmjs/libc.bc" for subsequent builds)
INFO:root: - ok
INFO:root:generating system library: wasm-libc.bc... (this will be cached in "/home/me/.emscripten_cache/asmjs/wasm-libc.bc" for subsequent builds)
INFO:root: - ok
INFO:root:generating system asset: generated_struct_info.json... (this will be cached in "/home/me/.emscripten_cache/asmjs/generated_struct_info.json" for subsequent builds)
Internal compiler error in src/compiler.js! Please raise a bug report at https://github.com/kripken/emscripten/issues/ with a log of the build and the input files used to run. Exception message: "ReferenceError: global is not defined" | load@/Projects/emscripten/src/modules.js:164:7
JSify@/Projects/emscripten/src/jsifier.js:87:5
@/Projects/emscripten/src/compiler.js:221:3

/Projects/emscripten/src/modules.js:164:7 ReferenceError: global is not defined
Stack:
  load@/Projects/emscripten/src/modules.js:164:7
  JSify@/Projects/emscripten/src/jsifier.js:87:5
  @/Projects/emscripten/src/compiler.js:221:3
Traceback (most recent call last):
  File "/Projects/emscripten/emcc.py", line 2997, in <module>
    sys.exit(run())
  File "/Projects/emscripten/emcc.py", line 1748, in run
    final = shared.Building.emscripten(final, append_ext=False, extra_args=extra_args)
  File "/Projects/emscripten/tools/shared.py", line 2253, in emscripten
    emscripten._main(cmdline)
  File "/Projects/emscripten/emscripten.py", line 2215, in _main
    return temp_files.run_and_clean(lambda: main(
  File "/Projects/emscripten/tools/tempfiles.py", line 93, in run_and_clean
    return func()
  File "/Projects/emscripten/emscripten.py", line 2220, in <lambda>
    DEBUG=DEBUG,
  File "/Projects/emscripten/emscripten.py", line 2146, in main
    temp_files=temp_files, DEBUG=DEBUG)
  File "/Projects/emscripten/emscripten.py", line 86, in emscript
    glue, forwarded_data = compiler_glue(metadata, libraries, compiler_engine, temp_files, DEBUG)
  File "/Projects/emscripten/emscripten.py", line 218, in compiler_glue
    glue, forwarded_data = compile_settings(compiler_engine, libraries, temp_files)
  File "/Projects/emscripten/emscripten.py", line 530, in compile_settings
    cwd=path_from_root('src'), error_limit=300)
  File "/Projects/emscripten/tools/jsrun.py", line 132, in run_js
    raise Exception('Expected the command ' + str(command) + ' to finish with return code ' + str(assert_returncode) + ', but it returned with code ' + str(proc.returncode) + ' instead! Output: ' + str(ret)[:error_limit])
Exception: Expected the command ['/home/me/build.gecko-dev/dist/bin/js', '-w', '/Projects/emscripten/src/compiler.js', '/tmp/tmp3akYdH.txt', '/Projects/emscripten/src/library_pthread_stub.js'] to finish with return code 0, but it returned with code 3 instead! Output: // The Module object: Our interface to the outside world. We import
// and export values on it. There are various ways Module can be used:
// 1. Not defined. We create it here
// 2. A function parameter, function(Module) { ..generated code.. }
// 3. pre-run appended it, var Module = {}; ..generated
FAIL: Compilation failed!
ERROR

======================================================================
ERROR: test_zero_multiplication (test_core.binaryen2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Projects/emscripten/tests/test_core.py", line 553, in test_zero_multiplication
    self.do_run_in_out_file_test('tests', 'core', 'test_zero_multiplication')
  File "/Projects/emscripten/tests/test_core.py", line 128, in do_run_in_out_file_test
    self.do_run_from_file(src, output, **kwargs)
  File "/Projects/emscripten/tests/runner.py", line 695, in do_run_from_file
    self.do_run(open(src).read(), open(expected_output).read(), *args, **kwargs)
  File "/Projects/emscripten/tests/runner.py", line 713, in do_run
    build_ll_hook=build_ll_hook, post_build=post_build)
  File "/Projects/emscripten/tests/runner.py", line 421, in build
    output = subprocess.check_call(args, stderr=self.stderr_redirect if not DEBUG else None)
  File "/usr/lib/python2.7/subprocess.py", line 186, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['/usr/bin/python2', '/Projects/emscripten/emcc.py', '-Werror', '-Wno-dynamic-class-memaccess', '-Wno-format', '-Wno-format-extra-args', '-Wno-format-security', '-Wno-pointer-bool-conversion', '-Wno-unused-volatile-lvalue', '-Wno-c++11-compat-deprecated-writable-strings', '-Wno-invalid-pp-token', '-Wno-shift-negative-value', '-O2', '-s', 'GL_DEBUG=0', '-s', 'EXCEPTION_CATCHING_WHITELIST=[]', '-s', 'INCLUDE_FULL_LIBRARY=0', '-s', 'ASMFS=0', '-s', 'TEXTDECODER=1', '-s', 'FINALIZE_ASM_JS=1', '-s', 'BINARYEN_ROOT=""', '-s', 'SPLIT_MEMORY=0', '-s', 'WEBGL2_BACKWARDS_COMPATIBILITY_EMULATION=0', '-s', 'LIBRARY_DEBUG=0', '-s', 'USE_CLOSURE_COMPILER=0', '-s', 'USE_SDL_IMAGE=1', '-s', 'SDL2_IMAGE_FORMATS=[]', '-s', 'INLINING_LIMIT=0', '-s', 'MODULARIZE=0', '-s', 'NO_FILESYSTEM=0', '-s', 'SYSTEM_JS_LIBRARIES=[]', '-s', 'FETCH_DEBUG=0', '-s', 'BINARYEN_TRAP_MODE="allow"', '-s', 'ERROR_ON_MISSING_LIBRARIES=0', '-s', 'SOCKET_WEBRTC=0', '-s', 'EVAL_CTORS=0', '-s', 'ELIMINATE_DUPLICATE_FUNCTIONS_DUMP_EQUIVALENT_FUNCTIONS=0', '-s', 'USE_PTHREADS=0', '-s', 'ENVIRONMENT_MAY_BE_WEB_OR_WORKER=1', '-s', 'USE_OGG=0', '-s', 'LEGACY_VM_SUPPORT=0', '-s', 'EXPORT_NAME="Module"', '-s', 'JSCALL_START_INDEX=0', '-s', 'AGGRESSIVE_VARIABLE_ELIMINATION=0', '-s', 'SIMPLIFY_IFS=1', '-s', 'ALIASING_FUNCTION_POINTERS=1', '-s', 'EMULATED_FUNCTION_POINTERS=0', '-s', 'EMSCRIPTEN_VERSION=""', '-s', 'OPENAL_DEBUG=0', '-s', 'JSCALL_SIG_ORDER={}', '-s', 'NO_EXIT_RUNTIME=0', '-s', 'RELOCATABLE=0', '-s', 'ENVIRONMENT=""', '-s', 'PRECISE_F32=0', '-s', 'DEBUG_TAGS_SHOWING=[]', '-s', 'USE_VORBIS=0', '-s', 'SAFE_HEAP_LOG=0', '-s', 'PROXY_TO_WORKER_FILENAME=""', '-s', 'LIBRARY_DEPS_TO_AUTOEXPORT=["memcpy"]', '-s', 'ASSERTIONS=0', '-s', 'QUANTUM_SIZE=4', '-s', 'PRECISE_I64_MATH=1', '-s', 'SEPARATE_ASM=0', '-s', 'GLOBAL_BASE=-1', '-s', 'STACK_OVERFLOW_CHECK=0', '-s', 'FORCE_FILESYSTEM=0', '-s', 'LZ4=0', '-s', 'ASM_JS=1', '-s', 'WARN_UNALIGNED=0', '-s', 'WASM_BINARY_FILE=""', '-s', 'ASMJS_CODE_FILE=""', '-s', 'EMULATE_FUNCTION_POINTER_CASTS=0', '-s', 'BINARYEN_PASSES=""', '-s', 'BINARYEN_SCRIPTS=""', '-s', 'TOTAL_STACK=5242880', '-s', 'TRACE_WEBGL_CALLS=0', '-s', 'BINARYEN_ASYNC_COMPILATION=1', '-s', 'EMTERPRETIFY_SYNCLIST=[]', '-s', 'RESERVED_FUNCTION_POINTERS=0', '-s', 'EXCEPTION_DEBUG=0', '-s', 'GL_PREINITIALIZED_CONTEXT=0', '-s', 'SWAPPABLE_ASM_MODULE=0', '-s', 'SHELL_FILE=0', '-s', 'GL_ASSERTIONS=0', '-s', 'BOOTSTRAPPING_STRUCT_INFO=0', '-s', 'MEM_INIT_METHOD=0', '-s', 'GL_TESTING=0', '-s', 'DETERMINISTIC=0', '-s', 'SAFE_HEAP=0', '-s', 'DEAD_FUNCTIONS=[]', '-s', 'USE_LIBPNG=0', '-s', 'ENVIRONMENT_MAY_BE_SHELL=1', '-s', 'GL_FFP_ONLY=0', '-s', 'EMSCRIPTEN_TRACING=0', '-s', 'OPT_LEVEL=0', '-s', 'MEMFS_APPEND_TO_TYPED_ARRAYS=0', '-s', 'NO_DYNAMIC_EXECUTION=0', '-s', 'BUILD_AS_WORKER=0', '-s', 'EXPORT_ALL=0', '-s', 'EMTERPRETIFY_ADVISE=0', '-s', 'VERBOSE=0', '-s', 'NODERAWFS=0', '-s', 'DISABLE_EXCEPTION_CATCHING=1', '-s', 'PTHREADS_PROFILING=0', '-s', 'EMTERPRETIFY_WHITELIST=[]', '-s', 'SKIP_STACK_IN_SMALL=1', '-s', 'STRICT=0', '-s', 'PROFILING_FUNCS=0', '-s', 'SOURCE_MAP_BASE=""', '-s', 'EMTERPRETIFY_ASYNC=0', '-s', 'FULL_ES2=0', '-s', 'FULL_ES3=0', '-s', 'OFFSCREENCANVAS_SUPPORT=0', '-s', 'USE_WEBGL2=0', '-s', 'PTHREADS_DEBUG=0', '-s', 'SIMD=0', '-s', 'PROXY_TO_WORKER=0', '-s', 'UNALIGNED_MEMORY=0', '-s', 'PROXY_TO_PTHREAD=0', '-s', 'FORCE_ALIGNED_MEMORY=0', '-s', 'EXTRA_EXPORTED_RUNTIME_METHODS=[]', '-s', 'FETCH=0', '-s', 'ASYNCIFY=0', '-s', 'TOTAL_MEMORY=16777216', '-s', 'USE_COCOS2D=0', '-s', 'USE_SDL_NET=1', '-s', 'SOCKET_DEBUG=0', '-s', 'ELIMINATE_DUPLICATE_FUNCTIONS_PASSES=5', '-s', 'EXPLICIT_ZEXT=0', '-s', 'STACK_START=-1', '-s', 'HEADLESS=0', '-s', 'USE_SDL=1', '-s', 'CASE_INSENSITIVE_FS=0', '-s', 'MAIN_MODULE=0', '-s', 'ASYNCIFY_WHITELIST=["qsort", "trinkle", "__toread", "__uflow", "__fwritex", "MUSL_vfprintf"]', '-s', 'MALLOC="dlmalloc"', '-s', 'SAFE_SPLIT_MEMORY=0', '-s', 'EXPORT_ES6=0', '-s', 'WEBSOCKET_URL="ws:#"', '-s', 'EMTERPRETIFY=0', '-s', 'DEBUG_LEVEL=0', '-s', 'SMALL_XHR_CHUNKS=0', '-s', 'USE_GLFW=2', '-s', 'WARN_ON_UNDEFINED_SYMBOLS=1', '-s', 'CYBERDWARF=0', '-s', 'ORIGINAL_EXPORTED_FUNCTIONS=[]', '-s', 'ONLY_MY_CODE=0', '-s', 'DEMANGLE_SUPPORT=0', '-s', 'RUNNING_JS_OPTS=0', '-s', 'WEBSOCKET_SUBPROTOCOL="binary"', '-s', 'INVOKE_RUN=1', '-s', 'PTHREAD_HINT_NUM_CORES=4', '-s', 'ENVIRONMENT_MAY_BE_WORKER=1', '-s', 'MODULARIZE_INSTANCE=0', '-s', 'PTHREAD_POOL_SIZE=0', '-s', 'SUPPORT_BASE64_EMBEDDING=0', '-s', 'DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=["memcpy", "memset", "malloc", "free"]', '-s', 'WASM=1', '-s', 'ENVIRONMENT_MAY_BE_WEB=1', '-s', 'EXPORT_FUNCTION_TABLES=0', '-s', 'SIDE_MODULE=0', '-s', 'USE_SDL_TTF=1', '-s', 'SINGLE_FILE=0', '-s', 'GL_MAX_TEMP_BUFFER_SIZE=2097152', '-s', 'EXPORT_BINDINGS=0', '-s', 'FS_LOG=0', '-s', 'STB_IMAGE=0', '-s', 'IGNORE_CLOSURE_COMPILER_ERRORS=0', '-s', 'RUNTIME_LOGGING=0', '-s', 'USE_HARFBUZZ=0', '-s', 'ELIMINATE_DUPLICATE_FUNCTIONS=0', '-s', 'ABORTING_MALLOC=1', '-s', 'SYSCALL_DEBUG=0', '-s', 'DEFAULT_PTHREAD_STACK_SIZE=2097152', '-s', 'PGO=0', '-s', 'IN_TEST_HARNESS=0', '-s', 'BUILD_AS_SHARED_LIB=0', '-s', 'EMTERPRETIFY_BLACKLIST=[]', '-s', 'LEGALIZE_JS_FFI=1', '-s', 'USE_FREETYPE=0', '-s', 'DOUBLE_MODE=1', '-s', 'BUNDLED_CD_DEBUG_FILE=""', '-s', 'MAX_GLOBAL_ALIGN=-1', '-s', 'EMTERPRETIFY_FILE=""', '-s', 'IMPLEMENTED_FUNCTIONS=[]', '-s', 'LEGACY_GL_EMULATION=0', '-s', 'STRUCT_INFO=""', '-s', 'RETAIN_COMPILER_SETTINGS=0', '-s', 'ENVIRONMENT_MAY_BE_NODE=1', '-s', 'EXPORTED_FUNCTIONS=["_main"]', '-s', 'RUNTIME_LINKED_LIBS=[]', '-s', 'EXPORTED_RUNTIME_METHODS=[]', '-s', 'MEM_INIT_IN_WASM=0', '-s', 'ALLOW_MEMORY_GROWTH=0', '-s', 'USE_BULLET=0', '-s', 'NODEJS_CATCH_EXIT=1', '-s', 'USE_ZLIB=0', '-s', 'WASM_TEXT_FILE=""', '-s', 'GL_UNSAFE_OPTS=1', '-s', 'BENCHMARK=0', '-s', 'WASM_MEM_MAX=-1', '-s', 'BINARYEN_METHOD="native-wasm"', '-s', 'LINKABLE=0', '-s', 'WASM_BACKEND=0', '-s', 'ASYNCIFY_FUNCTIONS=["emscripten_sleep", "emscripten_wget", "emscripten_yield"]', '-s', 'ERROR_ON_UNDEFINED_SYMBOLS=0', '-s', 'BINARYEN_IGNORE_IMPLICIT_TRAPS=0', '-s', 'OUTLINING_LIMIT=0', '-O2', '-I', '/tmp/emscripten_test_binaryen2_BiBhvU', '-I', '/tmp/emscripten_test_binaryen2_BiBhvU/include', '/tmp/emscripten_test_binaryen2_BiBhvU/src.cpp', '-o', '/tmp/emscripten_test_binaryen2_BiBhvU/src.cpp.o.js']' returned non-zero exit status 1

----------------------------------------------------------------------
Ran 1 test in 75.580s

FAILED (errors=1)
$

The key error seems to be "ReferenceError: global is not defined" | load@/Projects/emscripten/src/modules.js:164:7. Do you know what might be causing this?

[kripken]

It looks like that stack trace, inside the JS compiler, is coming from SpiderMonkey. That's probably not good - the only VM we test the compiler on is node.js. And indeed global is defined in node.js, but not other shells, which could explain that error. Does your .emscripten file set COMPILER_ENGINE to something other than NODE_JS? (I'll update the docs on this.)

However, this makes sense as a theory up to the point where you say asm.js tests pass but wasm ones do not - that global-using line of code should be hit in both cases, and the same VM used for the compiler as well...?

[sunfishcode]

When I switched to wasm, I got errors suggesting the node.js on my system doesn't support wasm. I have a spidermonkey shell build handy, so I thought that'd be the easiest thing to use instead. But I can get a newer node.js.

[sunfishcode]

I'm using a newer version of node now, which helps, but I'm still seeing some failures. It's not clear that they're due to my patch though; I just did a build from the incoming branches, without my patch, and I get the same failures. Here's an example:

$ tests/runner.py binaryen2.test_unistd_truncate_noderawfs
WARNING:tests/runner.py:use EM_ALL_ENGINES=1 in the env to run against all JS engines, which is slower but provides more coverage
Test suites:
['test_core']
Running test_core: (1 tests)
test_unistd_truncate_noderawfs (test_core.binaryen2) ... (checking sanity from test runner)
WARNING:root:did not see a source tree above or next to the LLVM root directory (guessing based on directory of /Projects/build.release/bin/llc), could not verify version numbers match
INFO:root:(Emscripten: Running sanity checks)
WARNING:root:java does not seem to exist, required for closure compiler, which is optional (define JAVA in /home/me/.emscripten if you want it)
WARNING:root:closure compiler will not be available
(test did not pass in JS engine: ['/Projects/node-v10.6.0-linux-x64/bin/node'])
ERROR

======================================================================
ERROR: test_unistd_truncate_noderawfs (test_core.binaryen2)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Projects/emscripten/tests/test_core.py", line 4877, in test_unistd_truncate_noderawfs
    self.do_run_from_file(src, output, js_engines=[NODE_JS])
  File "/Projects/emscripten/tests/runner.py", line 695, in do_run_from_file
    self.do_run(open(src).read(), open(expected_output).read(), *args, **kwargs)
  File "/Projects/emscripten/tests/runner.py", line 736, in do_run
    raise e
Exception: Expected to find 'st_size: 6

ftruncate(10): 0
errno: 0
st_size: 10

ftruncate(4): 0
errno: 0
st_size: 4

ftruncate(-1): -1
errno: 22
st_size: 4

truncate(2): 0
errno: 0
st_size: 2

truncate(readonly, 2): -1
errno: 13
st_size: 6

ftruncate(readonly, 4): -1
errno: 22
st_size: 6
' in 'f2: 10
st_size: 6

ftruncate(10): 0
errno: 0
st_size: 10

ftruncate(4): 0
errno: 0
st_size: 4

ftruncate(-1): 0
errno: 0
st_size: 0

truncate(2): 0
errno: 0
st_size: 2

truncate(readonly, 2): -1
errno: 13
st_size: 6

ftruncate(readonly, 4): -1
errno: 22
st_size: 6
', diff:

--- expected
+++ actual
@@ -1,3 +1,4 @@
+f2: 10
 st_size: 6

 ftruncate(10): 0
@@ -8,9 +9,9 @@
 errno: 0
 st_size: 4

-ftruncate(-1): -1
-errno: 22
-st_size: 4
+ftruncate(-1): 0
+errno: 0
+st_size: 0

 truncate(2): 0
 errno: 0



----------------------------------------------------------------------
Ran 1 test in 0.970s

FAILED (errors=1)
$

Is this expected?

[kripken]

It's probably ok to ignore those noderawfs tests for purposes of these PRs. But please file a separate bug, with your node version etc. - likely you are hitting a noderawfs issue that is OS or node version dependent.

[sunfishcode]

I filed #6895 to track the noderawfs failures.

As @kripken and I discussed offline, I've now set the version to 1.38.10, and will now merge!