getrlimit standards

["Theodore Y. Ts'o" <tytso@MIT.EDU>]

(I don't know if lsb-spec is going to be interested in this thread or
not --- if people think it's not relevant, I can remove the cc; IMO it's
borderline...)

Andrew,

	You that if I had questions on the Unix 98 spec I should let you
know..... so here's one.  The description for setrlimit() appears to be
very ambiguous as to what happens if RLIMIT_FSIZE is exceeded.  The text
says this:

>RLIMIT_FSIZE
>     This is the maximum size of a file in bytes that may be created by
>     a process. If a write or truncate operation would cause this limit
>     to be exceeded, SIGXFSZ is generated for the thread. If the thread
>     is blocking, or the process is catching or ignoring SIGXFSZ,
>     continued attempts to increase the size of a file from end-of-file
>     to beyond the limit will fail with errno set to [EFBIG].

Now then, what does "continued attempts" mean?  Normally if SIGXFSZ is
not caught, the process aborts.  Currently Linux (modulo a bug, which is
what called this to my attention) will send a SIGFXSZ signal, and return
EFBIG.  If the process doesn't die from the SIGFXSZ, then it will get
the EFBIG error.  

This appears to be compliant but for the "continued attempts" clause.
If process catches SIGXFSZ and ups the limit, should the system call
restart and retry the write?  Or should it return the number of bytes
written (possibly zero)?  I would presume that making the system call
restart and retrying the write would be the most friendly approach, but
it's also the hardest to implement.  Also, traditionally System V
systems didn't handle restarting system calls; so should write() return
EINTR instead?

This appears to be a corner case where the specification is not explicit
about what should happen.  I'm curious whether this is
accidental (i.e., an oversight) or deliberate (i.e., a desire to allow
multiple vendor's OSs to be compliant).

And what do you think Linux should do in the ideal case?  (Afterwards we
can see how hard it is to implement it --- but something as vague as
"continued attempts" makes me nervous.)

Many thanks!

							- Ted