sendfile.h appears to be missing from docker image emscripten/emsdk:3.1.3

[VirtualTim]

Edit: file was intentionally removed: emscripten-core/emscripten#14248

I'm attempting to update form trzeci/emscripten:1.39.6-upstream to emscripten/emsdk:3.1.3.
1.39.6 contains sendfile.h in /emsdk_portable/emscripten/sdk/system/include/libc/sys/.
3.1.3 does not contain sendfile.h in /emsdk/upstream/emscripten/cache/sysroot/include/sys/.
There are not other headers missing.

musl still ships sendfile.h https://github.com/emscripten-core/musl/tree/master/include/sys/,
however it's missing from https://github.com/emscripten-core/emscripten/tree/main/system/lib/libc/musl/include/sys/

[sbc100]

This was explicitly removed because we don't support it: emscripten-core/emscripten#14248. Is there some reason you need it?

[VirtualTim]

Not exactly. My project is a port of a ~20 year old codebase, and it was using sendfile (even though the functions using it were never actually called).
I've resolved this by adding a bunch of ifdefs, I was just confused why a previously included system header went missing.

[sbc100]

We have an ongoing tension in emscripten between what we declare in headers that we support and what we can actually support (either genuinely or via some kind of hack/emulation). Its not clear that we have a consistent policy here, but I'm inclined to remove declarations of things for which we don't even have a polyfil. There could be an argument for allowing as much code as possible to compile (in the hopes that at link time the reference will not be needed)... but I'm personally not persuaded by that.

I recently added two new settings that are somewhat related to this issue ALLOW_UNIMPLEMENTED_SYSCALLS and POLYFIL. Setting NO_ALLOW_UNIMPLEMENTED_SYSCALLS will cause programs that use unimpleent system calls to fail to link. Setting NO_POLYFIL only effects the JS polyfils we use on older browsers, but it could be argued that our dummy syscalls are a form a polyfill too.

[VirtualTim]

In general I agree, however if a user tries to compile something, and they get errors about missing /sys/ headers, they're probably going to assume they're something wrong with their environment, or Emscripten. I think it would be more developer/porter friendly if there was a "better" failure here, one that actually explains that the included header is not supported. I'm not really sure how to do that though, apart from adding a #error to all the unimplemented headers, and that seems pretty ugly. It's almost like we need a #include equivalent of NO_ALLOW_UNIMPLEMENTED_SYSCALLS that errors when including anything unimplemented from /sys/. I have no idea how you'd implement something like that though.
Well "need" might be too strong a term, but I think it would be useful.

[sbc100]

I think clang's builtin fatal error: 'foo.h' file not found message is a reasonable signal to the developer that that header file is not supported by that platform. When the developer sees such an error the compiler tells them exactly which file that include is coming from and IMHO its fairly direct signal to go look at that location and attempt to figure out how to avoid the include (often there are HAVE_XXX_H macros an such around includes which that developers can use to build the software without a given include).

A typical example would be "windows.h". I don't think we need to worry about adding a dummy copy of "window.h" with a #error in it. That seems like an endless road.. and while emscripten does do more hand-holding than other toolchains (e.g it can build zlib and other stdlibs for you behind the scenes) I think there are reasonable limits.

I also think the presence of such error headers in the include directory could harm understanding when a developer is simply browsing the list of available includes.

[VirtualTim]

Fair enough. Personally when I saw a missing system header that was there in previous version I assumed I messed up my environment, or Emscripten had messed up packaging. Hence why I created this issue when I saw the file was in musl.
But anyway I'm happy to consider this resolved with the doc update (emscripten-core/emscripten#16234).