Charles-François Natali added the comment: > Strange. I too modified Serchiy's code and my version of glibc (2.15) set the > error flag at the same fwrite call as errno was set: > > setvbuf 0 0 0 > fwrite 5 0 0 > fwrite 1 28 1 > fwrite 1 28 1 > > (the last column being the return value of ferror after each fwrite call)
Hum, you're right, I just re-ran the test, and I'm finding the same thing as you (I must have been dreaming). I just re-checked the glibc code, and indeed the write() error is checked, and the error flag is set: http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c#l1255 1241 _IO_ssize_t 1242 _IO_new_file_write (f, data, n) [...] 1251 count = (__builtin_expect (f->_flags2 1252 & _IO_FLAGS2_NOTCANCEL, 0) 1253 ? write_not_cancel (f->_fileno, data, to_do) 1254 : write (f->_fileno, data, to_do)); 1255 if (count < 0) 1256 { 1257 f->_flags |= _IO_ERR_SEEN; 1258 break; 1259 } But then this value is returned, and depending on the position in the buffer, this -1 ends up being incremented to what's left to write, and can result in returning exactly the same size that was requested. That's definitely a bug, and a bad one since you can get silent corruption (fclose() won't even return an error in most cases). Anyway, this means that ferror() should be enough - in addition to checking that the returned value matches. > I've trusted ferror until now but I'm not an expert on the subject. It's a > good point that errno is set by the underlying system call and is thus more > reliable. So would checking errno be sufficient (in addition to checking that > the lengths agree)? It can only serve to make file_write more robust. Yeah, would you like to write a patch? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17976> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
