Tobias S. Josefowitz wrote:
By the way, do you have any examples for when
commit 7def00d27ac7a31be123aaf7b63299d612d5802c Stdio.Buffer: Do not optimise the buffer to empty if there are subbuffers.
"generic data corruption bugs"? As far as I could see having a quick glance, all changes to the data and/or allocation should be guarded by io_add_space() (and thus result in io_add_space_do_something() throwing an error via io_ensure_unlocked()), thus even if ->len and ->offset are set to zero, no changes to data or allocation should occur. Maybe you actually did notice corruption in Shuffler instead?
Well, retracing my steps I can probably say the following: - Yes, you are correct, that would prevent most issues. - The reason I actually noticed corruption was because I extended the code first to allow appending (only) to buffers that are large enough already, even if they have subbuffers.
The code was/is not robust to begin with though. In io_add_space() the code was:
if( io->len == io->offset ) io->offset = io->len = 0; if( !force && io->malloced && !io->locked && io->len+bytes < io->allocated && (!bytes || io->len+bytes > io->len)) return io->buffer+io->len;
Checking for locked in the second if, and not in the first seems sloppy at best; defensive programming prescribes more robust checks here.