We've been assuming that by default, arrays have an underlying C array of 8 SVs, but that's not true, as far as I can tell. sv.c has that logic for hashes, but not for arrays. So we always call av_extend - even though it could be argued that it shouldn't be called for length=0 arrays, but the extra branch is probably not worth that comparatively rare special case.
It is easier on the encoder to encode the classname before it encodes whatever is blessed. So we swapped them around.
Some (most, right now) flags in the decoder are "static", IOW, they are not intended to be reset for each decoder run. For example, one of the flags marks the difference between a decoder that will be freed soon versus a decoder that will be reused. We were unconditionally unsetting all flags in various cleanup places. That was bad. Instead, we just unset all flags that pertain to the current decoder run.
Which I find weird. Could this be version dependent? It IS the case on 5.8.5. Yves
this allows a lot of subs to marked inline
Encoder isn't too bad now (including documentation for all three public functions), but the Decoder docs need a lot of work. We'll have to think carefully about how to implement protocol-level compatibility and how to expose it to Perl. Also, should we have a protocol spec exposed as POD somewhere?