Yes! Zero wouldn’t be considered as the default/standard return error value. I learnt the hard way today.
I had some kind of weird NULL pointer bug. After some investigations, i found that the deserialization function was failing at some point leaving the whole structure uninitialized. First i blamed myself for not calling the standard structure initialization function when the deserialization function failed. Then i looked at the data file.
Everything seemed to be ok. So i went on a step by step execution with the debugger. 5 minutes later i found the culprit. It was zlib in the kitchen with ten tone hammer. It was strange.
Let’s say that i compressed a buffer of N bytes into M bytes. When i read back the N bytes from the compressed buffer, i get the whole data before the end of the compressed buffer. Leaving me with 5 extra bytes.
On the next run i try to read P bytes. But i still have those 5 bytes to decompress. So i feed them to inflate (the zlib decompression routine). It returns a nice Z_STREAM_END. At this point, nothing wrong as i finished to process the previous compressed buffer. But (and that’s a big but … sorry ) no bytes were output.
In fact it’s an excellent news as we already get the N bytes back. So this bytes are … what… padding bytes ?
Anyway, the fact that i got 0 bytes back without any zlib or system error was a relief. But the “dezip” function is returning 0 on error or the size of the decompressed data when everything works…
So… I was considering that the “dezip” function failed even if everything was alright.
The whole issue was fixed in 5 minutes by changing the default error value from 0 to -1….
I spent the whole day tracking this bug…