From: Rainer Weikusat on
Casper H.S. Dik <Casper.Dik(a)Sun.COM> writes:
> Rainer Weikusat <rweikusat(a)mssgmbh.com> writes:
>
>>yirgster <yirg.kenya(a)gmail.com> writes:
>
>>[...]
>
>>> Yes, I'll keep this in mind for other circumstances. Thanks again. In
>>> this case an ENOSPC is a customer configuration/environment issue
>>> (lack of proper resource).
>
>>While this is IMO not compliant, some people believe that write
>>et. al. should return zero instead of signalling an error condition
>>when running out of space.
>
> They would be wrong:
>
> If a write() requests that more bytes be written than there is room for
> (for example, [XSI] [Option Start] the process' file size limit or
> [Option End] the physical end of a medium), only as many bytes as there
> is room for shall be written. For example, suppose there is space for
> 20 bytes more in a file before reaching a limit. A write of 512 bytes
> will return 20. The next write of a non-zero number of bytes would give
> a failure return.
>
> My reading of the standard says that write() can only return 0 when
> it is called with nbytes == 0.

I consider this the (only) sensible interpretation of this text,
too, but I have encountered at least one person which seemed to be
incapable to see any qualitative difference between the statements 'I
have 2 apples' and 'I have 0 apples', only a quantitative one: There
was room to write 0 bytes, because of this, only 0 bytes were written
and this reported to the caller of write. Someone with a sufficiently
twisted mind could even argue that write must not return ENOSPC if
nothing was written because the text says 'the next write of a
non-zero number of bytes would [...]', meaning, ENOSPC ought be
reported as soon as writes are possible again after a temporary lack
of space.