rt: open files non-inheritable on Windows; fix libc_sig's doc comment

The intermittent Windows CI failure -- "Permission denied" from inside
the runtime's unit tests, first seen at 4ad0166 -- is now named, by the
panic its fatal error makes in a test: a_field_window_outlives_its_file
closing a file and opening it again.

The C library's handles are inheritable by default on Windows, and the
unit tests that expect a fatal error run in child processes, beside the
file tests. A child started while a file was open for writing kept a
write handle of its own to it, so reopening the file -- which refuses
other writers (_SH_DENYWR, as the assembly runtime's CreateFileA did) --
failed for as long as the child lived. sys::open now adds MSVC's N mode
flag, so the handle stays in the process that opened it. The same would
have bitten a program the compiler runs, had the compiler started a child.

an_open_file_is_not_inherited_by_a_child reproduces it: under Wine it
failed with Permission denied before, and passes now.

Also: LIBC_FUNCTIONS had taken libc_sig's doc comment above its own; each
has its own again (review feedback).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Author: jgarzik

rt/src/file.rs

@@ -1343,6 +1343,31 @@ mod tests {
         );
     }
 
+    /// A file the program has open is not handed to a child process the
+    /// compiler or a test starts meanwhile. On Windows the C library's
+    /// handles were inheritable, so a child started while a file was open
+    /// for writing kept its own write handle to it; the file, closed and
+    /// opened again (which refuses other writers), was then "Permission
+    /// denied" for as long as the child lived. CI hit it when the unit tests
+    /// that run in child processes ran beside a file test.
+    #[cfg(windows)]
+    #[test]
+    fn an_open_file_is_not_inherited_by_a_child() {
+        let _g = serial();
+        let (_dir, path) = temp("inherit.txt");
+        open(&path, OUTPUT, 9);
+        put(9, "x");
+        // A child that outlives the close, started while the file is open.
+        let mut child = std::process::Command::new("cmd")
+            .args(["/c", "ping -n 3 127.0.0.1 >nul"])
+            .spawn()
+            .unwrap();
+        unsafe { _rt_file_close(9) };
+        open(&path, OUTPUT, 9);
+        unsafe { _rt_file_close(9) };
+        let _ = child.wait();
+    }
+
     /// A FIELD variable is a window onto its file's record buffer, and
     /// outlives the OPEN that made it: a re-OPEN of the number, sequential or
     /// RANDOM, freed the buffer, and LSET then wrote freed memory and PRINT

rt/src/sys.rs

@@ -550,11 +550,29 @@ mod windows {
     /// assembly runtime's CreateFileA did with FILE_SHARE_READ: a second
     /// writer is refused, which is "Permission denied".
     ///
+    /// And not inherited (`N`): the C library's handles are inheritable by
+    /// default, so a child process started while the file was open -- by a
+    /// test, or by the compiler around a program it runs -- kept a write
+    /// handle of its own, and the program's next OPEN of the file, refusing
+    /// other writers, was "Permission denied" while the child lived.
+    ///
     /// # Safety
     /// Both must be NUL-terminated.
     pub unsafe fn open(name: *const c_char, mode: *const c_char) -> *mut FILE {
         const _SH_DENYWR: c_int = 0x20;
-        unsafe { _fsopen(name, mode, _SH_DENYWR) }
+        // The mode, then N. Modes are a few letters ("r+b" at most).
+        let mut with_n = [0u8; 8];
+        let mut n = 0;
+        while n < with_n.len() - 2 {
+            let c = unsafe { *mode.add(n) } as u8;
+            if c == 0 {
+                break;
+            }
+            with_n[n] = c;
+            n += 1;
+        }
+        with_n[n] = b'N';
+        unsafe { _fsopen(name, with_n.as_ptr().cast(), _SH_DENYWR) }
     }
 
     /// Why the open just made failed. errno alone cannot say: the CRT maps

src/codegen/mod.rs

@@ -538,13 +538,13 @@ fn rt_type(t: rtsig::Ty) -> Type {
     }
 }
 
-/// The C library functions generated code calls, with their signatures.
 /// The C library functions generated code calls, all of them.
 pub(crate) const LIBC_FUNCTIONS: [&str; 12] = [
     "pow", "sin", "cos", "tan", "atan", "exp", "log", "calloc", "realloc", "free", "memset",
     "memcpy",
 ];
 
+/// The C library functions generated code calls, with their signatures.
 fn libc_sig(name: &str) -> (&'static [Type], &'static [Type]) {
     debug_assert!(LIBC_FUNCTIONS.contains(&name), "{name} is not listed");
     const F: &[Type] = &[types::F64];