2018-05-13 18:03 GMT+02:00 Elvis Stansvik <elvst...@gmail.com>: > 2018-05-13 14:58 GMT+02:00 william.croc...@analog.com > <william.croc...@analog.com>: >> >>> >>> 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. >>> >> >> I agree with the existing behavior but I, like many users I am sure, >> got bitten by this behavior as well. I think this is one of many cases >> where the documentation should point out the error in making common >> assumptions about how the function works. >> >> Writes at most maxSize bytes of data from data to the device. >> Returns the number of bytes that were actually written, >> or -1 if an error occurred. > > Hm, maybe that could be improved upon, but personally I think it's very clear. > > The docs says "at most maxSize bytes". Both the name of the parameter > and the phrasing here makes it clear that it can write less. > > Furthermore, it says the function returns either the number of bytes > that were _actually_ written, or -1 if an error occurred. The very > fact that -1 return value is used as an error indicator makes it clear > that partial writes is not considered an error (for they would result > in != -1 return value). > > I also don't think it would be a common assumption that a write > function that reports the number of bytes written would always write > everything requested. Like Thiago said this is precisely how the > regular write(2) in POSIX works, and WriteFile on Windows. If it would > always write everything, why would it even bother with reporting how > much was written?
But, I do think that the paragraph that follow should be removed: When reimplementing this function it is important that this function writes all the data available before returning. This is required in order for QDataStream to be able to operate on the class. QDataStream assumes all the information was written and therefore does not retry writing if there was a problem. Because that is just misleading and does not reflect the reality of the QIODevice-subclasses within Qt itself. QDataStream can operate fine on an QIODevice that does partial writes (like QFile). The QDataStream will operate as advertised, it's just that it'll go into WriteFailed state (see status()) if a write failed. Elvis > > Elvis > >> >> That would come in first place in a competition for providing >> the least documentation possible. Perhaps is should also say... >> >> The number of bytes written is returned for a reason. >> You should check it and be prepared to take appropriate >> action if it is less than the expected value. >> Also note that writing less than the expected number of bytes >> is not, by itself, considered to be an error. >> ... >> >> Bill >> >> >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
