…or something else later)
Now you can do: perl -x srl_decoder.h to autoupdate the string table from the defines.
Perl stores hashes in two forms: UTF8 and Latin-1 (binary). If a unicode key is stored in a hash then perl will see if it can be reencoded as latin-1 (binary). If it can then it is stored as latin-1 with the flag "WASUTF8". If it cant then it is stored as utf8 with the flag ISUTF8. If the key is latin-1/binary from the beginning then it is stored as latin-1 with neither flag set. When fetching the keys of a hash and the key has the WASUTF8 then perl upgrades the string before returning it to the user so it has the correct semantics. This means that we also have to do the same thing for WASUTF8 keys or they will not round trip properly.
This reverts commit df5c7d3. Collision with Yves' more complete fix.
Part of this patch also switches from using direct bitmap tests for ASCII tags with macros. This makes it easier to ensure all of these tests work properly should we need to change the logic.
It seems that back in the mists of time there was a static hv_fetch_common() which was refactored into hv_common(). So on ancient perls use hv_fetch().
We need many more tests for aliases. :-(
For internal test release.
Due to how MakeMaker works, we need to maintain separate copies of the code in inc/ (which is required for Makefile.PL). Symlinks fuck of the make dist and make manifest stages of distribution building and we really don't want that. Yves, if this breaks your build again, try a fresh clone!
We also switch to using hv_common in a more intelligent way. This improves performance, and I dont think it actually violates the API either.
This seems necessary for dist/manifest building.
Regexp logic was in the wrong place, and we werent created hashes with shared keys properly
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.