--- JSON-XS/XS.xs 2008/06/22 12:05:49 1.88 +++ JSON-XS/XS.xs 2008/09/29 03:09:27 1.93 @@ -196,7 +196,7 @@ { if (expect_false (enc->cur + len >= enc->end)) { - STRLEN cur = enc->cur - SvPVX (enc->sv); + STRLEN cur = enc->cur - (char *)SvPVX (enc->sv); SvGROW (enc->sv, cur + len + 1); enc->cur = SvPVX (enc->sv) + cur; enc->end = SvPVX (enc->sv) + SvLEN (enc->sv) - 1; @@ -282,14 +282,13 @@ } else { - static char hexdigit [16] = "0123456789abcdef"; need (enc, len += 5); *enc->cur++ = '\\'; *enc->cur++ = 'u'; - *enc->cur++ = hexdigit [ uch >> 12 ]; - *enc->cur++ = hexdigit [(uch >> 8) & 15]; - *enc->cur++ = hexdigit [(uch >> 4) & 15]; - *enc->cur++ = hexdigit [(uch >> 0) & 15]; + *enc->cur++ = PL_hexdigit [ uch >> 12 ]; + *enc->cur++ = PL_hexdigit [(uch >> 8) & 15]; + *enc->cur++ = PL_hexdigit [(uch >> 4) & 15]; + *enc->cur++ = PL_hexdigit [(uch >> 0) & 15]; } str += clen; @@ -463,7 +462,7 @@ // for canonical output we have to sort by keys first // actually, this is mostly due to the stupid so-called - // security workaround added somewhere in 5.8.x. + // security workaround added somewhere in 5.8.x // that randomises hash orderings if (enc->json.flags & F_CANONICAL) { @@ -1420,10 +1419,19 @@ * assertion with -DDEBUGGING, although SvCUR is documented to * return the xpv_cur field which certainly exists after upgrading. * according to nicholas clark, calling SvPOK fixes this. + * But it doesn't fix it, so try another workaround, call SvPV_nolen + * and hope for the best. + * Damnit, SvPV_nolen still trips over yet another assertion. This + * assertion business is seriously broken, try yet another workaround + * for the broken -DDEBUGGING. */ - SvPOK (string); +#ifdef DEBUGGING + offset = SvOK (string) ? sv_len (string) : 0; +#else + offset = SvCUR (string); +#endif - if (SvCUR (string) > json->max_size && json->max_size) + if (offset > json->max_size && json->max_size) croak ("attempted decode of JSON text of %lu bytes size, but max_size is set to %lu", (unsigned long)SvCUR (string), (unsigned long)json->max_size);