[lkml]   [2001]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] s_maxbytes handling
In article <>,
Alan Cox <> wrote:
>> > verification tests. So unless you can cite page and paragraph from SuS and
>> > the LFS spec I think the 0 might in fact be correct..
>> I don't know the standards Alan, but returning zero
>> from write() when f_pos is at s_maxbytes will make
>> a lot of apps hang up. dd, bash and zsh certainly do.
>> Are they buggy? Should they be testing the return value
>> of write() and assuming that zero is file-full?
>0 is an EOF.

0 is EOF _for_reads_. For writes it is not very well defined (except for
the special case of a zero-sized write to a regular file).

For writes, 0 has historically been what Linux has returned for various
"disk full" conditions, and seems to be what programs such a "tar"
actually expected for end of disk. Also, traditionally a lot of UNIXes
returned 0 when O_NDELAY was set and they couldn't write anything (ie
the modern EAGAIN).

An application seeing a zero return from a write with a non-zero buffer
size cannot really assume much about what it means. The best you can
probably do is to fall back and say "no more space on device", but
obviously a lot of programmers who are used to testing only for _real_
errors will not even think about considering 0 an error value.

So returning 0 for write() is usually a bad idea - exactly because it
does not have very well-defined semantics. So -EFBIG is certainly the
preferable return value, and seems to be what SuS wants, too.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.037 / U:6.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site