Yes! Zero wouldn’t be considered as the default\/standard return error value. I learnt the hard way today.<\/p>\n
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. 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. The whole issue was fixed in 5 minutes by changing the default error value from 0 to -1….<\/p>\n I spent the whole day tracking this bug…<\/p>\n","protected":false},"excerpt":{"rendered":" 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\u2026 Continue reading<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[27],"_links":{"self":[{"href":"https:\/\/blog.blockos.org\/index.php?rest_route=\/wp\/v2\/posts\/23"}],"collection":[{"href":"https:\/\/blog.blockos.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.blockos.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.blockos.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.blockos.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=23"}],"version-history":[{"count":0,"href":"https:\/\/blog.blockos.org\/index.php?rest_route=\/wp\/v2\/posts\/23\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.blockos.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=23"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.blockos.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=23"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.blockos.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=23"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nEverything 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<\/a> in the kitchen with ten tone hammer. It was strange.<\/p>\n
\nOn the next run i try to read P bytes. But i still have those 5 bytes to decompress. So i feed them to inflate<\/a> (the zlib decompression routine). It returns a nice Z_STREAM_END<\/a>. 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.
\nIn fact it’s an excellent news as we already get the N bytes back. So this bytes are … what… padding bytes ?
\nAnyway, the fact that i got 0 bytes back without any zlib<\/a> 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…
\nSo… I was considering that the “dezip” function failed even if everything was alright.<\/p>\n