I noticed while debugging an unrelated test that our use of the null driver has a habit of making functions like find_image_format trigger a lot of uninitialized memory errors in valgrind, because it will return a successful read without actually touching the buffer.
I see that in March there was a bit of a debate over whether or not the null driver SHOULD zero-write memory for performance reasons, but when this option isn't specified, the semantics of read are arguably broken. This isn't terribly important to fix, but for actual debugging purposes it's nice to not have valgrind screaming at you with spurious junk. A few options: (1) Admit that it's weird to allow reads to succeed with null-co driver. Annoy people who apparently wanted performance for their do-nothing driver and force the initialization of memory. --or-- (1a) Use valgrind macros to pretend the memory has been initialized. (2) Band-aid find_image_format to zero-initialize memory. Wonder if there are other usages of read() getting called from tests that utilize null-co that will make debugging difficult in other contexts. (3) Edit any tests to always use the zero option when using the null driver, and then periodically keep updating this option in a losing battle over time. (4) Find a way to adjust return value of null-co's read implementation to return 0 instead of a lie over the number of bytes it read/wrote. Correctly represents "No bytes written, but no error occurred either." (5) Shut up, John, really, who cares? Please shut up. You are the only idiot who would even think to use valgrind ever, and we just don't like you that much. All are kind of bad options, but I like (5) the least. --js
