mirror of
https://github.com/fluffos/fluffos
synced 2026-08-12 18:26:06 -04:00
Follow-up to reviewing PRs #1068 and #932, both of whose bugs are already fixed on master: - #1068 (call_out handles below the allocation counter rejected as invalid) was fixed by #1220 with a regression test in testsuite/single/tests/efuns/remove_call_out.lpc. Document the guaranteed semantics in call_out.md / remove_call_out.md: a handle stays valid until it fires or is removed, regardless of newer call_outs; 0 is never a valid handle. - #932 (an error thrown from valid_read during #include handling left compile_file's reentrancy guard set, wedging all future loads) is fixed by the compiler front-end rewrite: compile_file's scope guard restores all compiler state and clears the guard on exception unwinding. Document in valid_read.md that the apply runs mid-compile for #include checks, must not trigger another compile, and that a thrown error aborts only that compilation. Claude-Session: https://claude.ai/code/session_01JRvUnh3x5MYPWPk2MiiUS2 Co-authored-by: Claude <noreply@anthropic.com>
1.2 KiB
1.2 KiB
| title |
|---|
| master / valid_read |
valid_read
NAME
valid_read - checks if a certain person has read permission on a file
SYNOPSIS
int valid_read( string file, mixed user, string func );
DESCRIPTION
Every time a user tries to read a file, the driver calls valid_read in
the master object to check if the read should be allowed. The argu‐
ments are the filename, the name of the person making the read, and the
calling function name. If valid_read returns non-zero, the read is
allowed.
This apply is also consulted in the middle of compiling an object: each
#include directive checks the header path with valid_read (with <func>
set to "include") before opening it. Returning 0 denies the include and
fails that compile. Because the apply runs mid-compile, it must not
trigger another compile itself (e.g. by loading an object). A runtime
error thrown from valid_read (or anywhere else while a file is being
compiled) aborts that compilation cleanly; the driver fully unwinds its
compiler state and remains able to load other objects afterwards.
SEE ALSO
valid_write(4), include_file(4), inherit_program(4)