RLIMIT_FSIZE and SIGXFSZ

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

The documentation I have (which is consistent across 1.4T, 4.0.1, and
5.2) says that "[a] file I/O operation that would create a file larger
that the process' soft limit will cause the write to fail and a signal
SIGXFSZ to be generated".  I looked at the code (for 4.0.1, that being
what's on the machine I care about at the moment) and this appears to
be accurate.

It seems to me it would be more useful to do something like what
RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
them only when the size exceeds the hard limit.  As it stands, the hard
limit is useful only as a value the soft limit can't be raised above.
("More useful" to me, at any rate.)

It looks fairly simple to do.  UFS, for example, says
(ufs/ufs/ufs_readwrite.c)

        l = curlwp;
        if (vp->v_type == VREG && l &&
            uio->uio_offset + uio->uio_resid >
            l->l_proc->p_rlimit[RLIMIT_FSIZE].rlim_cur) {
                psignal(l->l_proc, SIGXFSZ);
                return (EFBIG);
        }

and I can't see any reason it wouldn't work to

        l = curlwp;
        if (vp->v_type == VREG && l &&
            uio->uio_offset + uio->uio_resid >
            l->l_proc->p_rlimit[RLIMIT_FSIZE].rlim_cur) {
                psignal(l->l_proc, SIGXFSZ);
-               return (EFBIG);
+               if (uio->uio_offset + uio->uio_resid >
+                   l->l_proc->p_rlimit[RLIMIT_FSIZE].rlim_max)
+                       return (EFBIG);
        }

with a corresponding change to getrlimit(2) to describe the new
behaviour (and, of course, similar changes in the other places SIGXFSZ
is generated).

Comments or other thoughts?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B