Thanks for the report. The problem stems from this line

For comparison gcc sets the executable bit of the output file if it is a regular file that already exists, but not in the case of /dev/null, which it leaves untouched.

For comparison gcc sets the executable bit of the output file if it is a regular file that already exists

This is a reasonable strategy, but we cannot implement it in ocamlc (currently) because the Sys portable interface doesn't give direct access to stat and to chmod, and I'd rather keep it this way. The question, then, is to find a minimal extension to Sys (or perhaps to Out_channel) that does what we want.

Let's not rush a fix. The "problem" has been with us since 2003, and sane users don't run compilers with superuser privileges.

In passing, #9787 proposed caml_sys_chmod as a primitive only (i.e. an external ocamlc could declare and use).

caml_sys_is_directory already uses stat for Sys.is_directory - would adding caml_sys_is_regular be OK? Sys.is_regular_file seems OK to add, and we could then keep the existing "delete if exists strategy" (which would avoid adding caml_sys_chmod and then pretending that it's not there in the stdlib)

I'm not saying what I was doing is sane (pretty much the opposite: fighting with a very non OCaml-friendly environment and build system), but there is now a common situation where we can expect users to run about anything as root: docker. Not saying it's a good idea, but the simple normal and common setup is to be root inside the container, as far as I know.

there is now a common situation where we can expect users to run about anything as root: docker. Not saying it's a good idea, but the simple normal and common setup is to be root inside the container, as far as I know.

It certainly doesn't need to be that way - deploying in Docker as root is one thing, but using it as a development environment, one should create a non-privileged user in the normal way. cf. the opam images at ocaml/opam on Docker hub which all have an opam normal user.

Sys.is_regular_file seems OK to add,

Agreed. I had a more complicated fix in mind, but here is a fix based on Sys.is_regular_file: #11412.

For the record, the alternate solution I had in mind is here: xavierleroy@d898922 . The good thing about this alternate solution is that the bytecode file generated by ocamlc is not executable until it's complete and ready for execution. The not so good thing is that the final permissions are harder to predict.