* Move spl_offset_convert_to_long() to spl_fixedarray.c
It is only used there, which explains its weird offset semantics
* Refactor SplFixedArray offset handling
- Implement warning for resource type
- Throw a proper TypeError instead of a RuntimeException
* Use a proper Error to signal that [] cannot be used with SplFixedArray
* Refactor SplFixedArray has_dimension helper
* Drop some ZPP tests
Rather than using def_info, check against the actual arg_info type.
As it is stored as a type mask nowadays, this is not much harder,
but more general and more robust as we don't need to deal with
inaccurate cases.
That happens on Travis s390x for whatever reasons. Thus, instead of
checking for `fallocate -h`, we attempt the real allocation and skip if
that fails.
When mapping the file, we need to pass the proper `dwFileOffsetHigh`
instead of `0`.
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
Closes GH-7158.
Previously, mbstring would accept a lot of things which were not valid
UHC text. No more.
- Don't allow single-byte control characters to appear where the 2nd
byte of a multi-byte character should be.
- Validate that the 2nd byte of a multi-byte character is in the
expected range.
- Treat it as an error if a multi-byte character is truncated.
Also add a test suite to confirm that UHC conversion (both to and from
Unicode) works according to spec.
Sigh. Double sigh. After fruitlessly searching the Internet for information on
this mysterious text encoding called "SJIS-open", I wrote a script to try
converting every Unicode codepoint from 0-0xFFFF and compare the results from
different variants of Shift-JIS, to see which one "SJIS-open" would be most
similar to.
The result? It's just CP932. There is no difference at all. So why do we have
two implementations of CP932 in mbstring?
In case somebody, somewhere is using "SJIS-open" (or its aliases "SJIS-win" or
"SJIS-ms"), add these as aliases to CP932 so existing code will continue to
work.
Also fix a couple small problems with UTF-32 and UTF-8 support:
- UTF-32 would pass very large codepoints (>= 0x80000000), which are
not valid.
- UTF-8 would sometimes emit two error marker characters for a single
bad input byte.
This test fails on s390x with opcache. Presumably the large allocation
works fine there as long as it's not used.
Switch to a different error condition that produces a more reliable
failure.
We only load a minimum set of extensions, and rely on dynamic loading
of others due to `--EXTENSION--` triggers. We do not run the imap,
ldap and snmp test suites, because most of the tests would be skipped
after timeouts anyway.
Closes GH-7150.
We have bumped the libcurl requirement to 7.29.0 in PHP 8.1,
but the function declarations in the stubs were still conditional
on the curl version. Drop them to make it more obvious that these
functions are always available.
