On Monday, 14 May 2018 09:17:42 PDT Roland Hughes wrote:
> > ?That is simply incorrect. It might not be how you would like it to
> > behave,
> > however it is the norm that short writes are allowed and should be handled
> > by the callee. This is the case in POSIX, the C standard library etc. I'm
> > afraid, you'll simply have to learn to live with it - an easy solution
> > would be to write a tiny wrapper function of your own however if you do
> > you'll need to be very careful with your error handling if you always want
> > to be able to retry.
>
> Your statement would be patently false.
> =====
> FREAD(3) Linux Programmer's Manual FREAD(3)
Ok, so not the standard C library. But it is still the case for POSIX and
Win32.
In fact, the man page for write(2) says specifically
[...] It is not an error if this number is smaller
than the number of bytes requested; this may happen for example
because the disk device was filled.
See http://man7.org/linux/man-pages/man2/write.2.html
Looping trying to write more after short writes is a good idea in some
circumstances, but could be bad in others. We can't tell why the short write
happened: it may have been interrupted by a signal, which means we could
easily resume without further harm. But trying to write more could trigger an
actual error, which means we need a path to handling it. You can't count on
subsequent writes producing the same error.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
