[Interest] QFile::write(const QByteArray&) does not, , write, all data?
Roland Hughes
roland at logikalsolutions.com
Wed May 16 14:59:19 CEST 2018
On 05/16/2018 06:04 AM, Thiago Macieira wrote:
> 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.
>
> Seehttp://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.
Odd that the man page you chose to quote would contradict itself.
http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/Errors/unix_system_errors.html
#define ENOSPC 28 /* No space left on device */
It's not an error for write() to fail because of an error.
What we have here is a failure to architect. (Just can't use "the voice"
in email though.)
https://www.youtube.com/watch?v=Oik6dXm-0l0
Classic *nix. Returning -1 to indicate error and praying to some deity
that something else actually caught the error _and_ that the developer
will be able to find where said error is stored before it gets
overwritten by another error.
It is always a design error to use a single value entity to communicate
two different things, especially when those things can overlap. A device
full error potentially wrote all by the last byte. If your environment
isn't Posix 1c compliant, by the time you get around to fetching errno
it could have been overwritten.
https://stackoverflow.com/questions/1694164/is-errno-thread-safe
In the OOP world, there is no excuse for this. A class can keep an
internal member variable where the errno value (or translation of it) is
stored. At the beginning of each I/O operation the variable is cleared
and if error encountered the errno value is immediately captured. A
class can provide a method to retrieve this value so the I/O methods
__always__ return the number of bytes written and the application can
check the error value any time the count doesn't match.
Yes, the methods performing the I/O must capture this value and any
device specific error values. In OOP with classes derived from classes
derived from classes a great many instructions which could set a
different errno value might have executed.
#define EOVERFLOW 75 /* Value too large for defined data type */
That's a nice one. The failed I/O left garbage somewhere and some other
code tried to use it. Now errno tells you the symptom instead of the
disease.
As I recall, the POSIX spec was written for C. They __had__ to make the
contradictory statement that a short read/write was not an error because
they ran smack dab into the middle of the overlap. SOME I/O might have
happened and that value had to be returned. ___Hopefully___ the
developer can find the real error on their own.
Qt is written in C++ so it can do better.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180516/b821861d/attachment.html>
More information about the Interest
mailing list