…ally not if they aren't in 5.4, too.
… 2093 for successful XFAIL)
Use salt_len_in instead of strlen(salt) or PHP_MAX_SALT_LEN, otherwise too much memory will be allocated. sha512 has a 86 character checksum, not 43. That probably was a copy&paste from the sha256 code which indeed has 43. The allocation also was using sizeof(char *), thus allocating 4 or 8 times as much memory as necessary. The sizeof(char *) was removed in the 5.4 branch in b7a92c9 but forgotten on 5.3. The memset 0 call was using PHP_MAX_SALT_LEN which can be smaller than the output buffer and thus not zeroing out everything. Use the size of the output buffer (needed) instead.
Fixed a memory allocation bug in crypt() SHA256/512 that can cause segmentation faults when passed in salts with a null byte early.
This replaces json_last_error(true) and is consistent with other custom error handling functions.
This fixes the same issue in multiple extensions. This isn't needed in later branches as 5.4 introduced object_properties_init()
json_encode() no longer throws warnings. Instead only the error code for json_last_error() is set. As it is hard to debug the error from just an error code an optional $as_string parameter was added to json_last_error(), which returns an error message instead of an error code.
base64_encode used safe_emalloc, but one of the arguments was derived from a multiplication, thus making the allocation unsafe again. There was a size check in place, but it was off by a factor of two as it didn't account for the signedness of the integer type. The unsafe allocation is not exploitable, but still causes funny behavior when the sized overflows into a negative number. To fix the issue the *4 factor is moved into the size argument (where it is known to be safe), so safe_emalloc can carry out the multiplication. The size check is removed as it doesn't really make sense once safe_emalloc works correctly. (Would only cause base64_encode to silently return false instead of throwing an error. Also could cause problems with other uses of the base64 encoding API, which all don't check for a NULL return value.) Furthermore the (length + 2) < 0 check is replaced with just length < 0. Allowing lengths -2 and -1 doesn't make sense semantically and also is not honored in the following code (negative length would access unallocated memory.) Actually the length < 0 check doesn't make sense altogether, but I left it there just to be safe.
json_encode() now returns bool(false) for all possible errors, throws the respective warning and also sets the respective json_last_error() error code. Three new error codes have been added: * JSON_ERROR_RECURSION * JSON_ERROR_INF_OR_NAN * JSON_ERROR_UNSUPPORTED_TYPE To get a partial JSON output instead of bool(false) the option JSON_PARTIAL_OUTPUT_ON_ERROR can be specified. In this case the invalid segments will be replaced either by null (for recursion, unsupported type and invalid JSON) or 0 (for Inf and NaN). The warning for invalid UTF-8 stays intact and is thrown also with display_errors = On. If this behavior is undesired this can be remedied later.
ArrayIterator implemented Countable only after it was already inherited by RecursiveArrayIterator. Thus the interface was missing in RAI.