[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