summaryrefslogtreecommitdiff
path: root/ext/mbstring/mbstring.stub.php
Commit message (Collapse)AuthorAgeFilesLines
* Generate class entries from stubs for ldap, libxml, mbstring and mysqliMáté Kocsis2021-02-161-1/+1
| | | | Closes GH-6684
* Normalize mb_ereg() return valueNikita Popov2020-10-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mb_ereg()/mb_eregi() currently have an inconsistent return value based on whether the $matches parameter is passed or not: > Returns the byte length of the matched string if a match for > pattern was found in string, or FALSE if no matches were found > or an error occurred. > > If the optional parameter regs was not passed or the length of > the matched string is 0, this function returns 1. Coupling this behavior to the $matches parameter doesn't make sense -- we know the match length either way, there is no technical reason to distinguish them. However, returning the match length is not particularly useful either, especially due to the need to convert 0-length into 1-length to satisfy "truthy" checks. We could always return 1, which would kind of match the behavior of preg_match() -- however, preg_match() actually returns the number of matches, which is 0 or 1 for preg_match(), while false signals an error. However, mb_ereg() returns false both for no match and for an error. This would result in an odd 1|false return value. The patch canonicalizes mb_ereg() to always return a boolean, where true indicates a match and false indicates no match or error. This also matches the behavior of the mb_ereg_match() and mb_ereg_search() functions. This fixes the default value integrity violation in PHP 8. Closes GH-6331.
* Update mbstring parameter namesNikita Popov2020-09-281-30/+30
| | | | Closes GH-6207.
* Standardize mbstring and string on using 'string' as a parameter name.Larry Garfield2020-09-211-15/+15
| | | | Closes GH-6171.
* Promote a few remaining errors in ext/standardMáté Kocsis2020-09-151-1/+1
| | | | Closes GH-6110
* Make mb_send_mail() consistent with mail()Máté Kocsis2020-09-141-1/+1
| | | | The $additional_headers parameter shouldn't accept null.
* Move custom type checks to ZPPMáté Kocsis2020-09-021-2/+1
| | | | Closes GH-6034
* Add a few missing parameter types in stubsMáté Kocsis2020-07-301-1/+4
| | | | Related to GH-5627
* Fix UNKNOWN default values in ext/mbstring and ext/gdMáté Kocsis2020-07-281-43/+44
| | | | Closes GH-5598
* Fix mb_ereg_search* arg and func infoNikita Popov2020-07-211-3/+3
|
* Fix [-Wundef] warning in MBString extensionGeorge Peter Banyard2020-05-161-1/+1
|
* Refactor mb_substitute_character()George Peter Banyard2020-05-111-2/+1
| | | | | | Using the new Fast ZPP API for string|int|null This also fixes Bug #79448 which was too disruptive to fix in PHP 7.x
* Convert if blocks to assertions and adapt stubs accordinglyGeorge Peter Banyard2020-04-091-9/+9
|
* Update mb_strrpos() stubNikita Popov2020-04-081-1/+1
| | | | | We no longer accept the encoding as 3rd param, so we can make this a proper int argument.
* Generate function entries for another batch of extensionsMáté Kocsis2020-04-051-0/+2
| | | | Closes GH-5352
* Promote invalid case mode to ValueError in mb_case_converterGeorge Peter Banyard2020-04-051-3/+3
| | | | | | Add assertions to check the return value is not NULL as this indicates a bug. Add identical assertion to mb_strtoupper and mb_strtolower. This means these functions can't return false anymore, ammend stubs accordingly.
* mb_scrub() can't return false anymoreGeorge Peter Banyard2020-04-051-1/+1
| | | | Also drop the intermediary function which was only used here
* Refactor mb_substr_count()George Peter Banyard2020-04-021-1/+1
| | | | | | Promote empty needle warning to ValueError Convert if branch into an assertion as if mbfl_substr_count fails this now implies a bug Thus mb_substr_count() can only return int now, fix stubs accordingly
* Convert if branch to assertion in mb_strlenGeorge Peter Banyard2020-04-021-1/+1
| | | | | This operation should never fail, therefore it's converted to an assertion. Thus this mb_strlen() can now only return int, fix stubs accordingly
* Promote mb_str_split warning to ValueErrorGeorge Peter Banyard2020-04-021-1/+1
| | | | | | Also add a TODO about documenting this funcion on PHP.net Convert some checks to assertions as if they don't hold something went wrong during memory allocation Due to these changes this function cannot return false anymore, fix stubs accordingly
* mb_detect_order(): Use proper array|string argumentNikita Popov2020-03-301-1/+1
|
* mb_check_encoding(): Make var a proper array|string argNikita Popov2020-03-301-1/+2
|
* mb_detect_encoding(): Use proper array|string parameterNikita Popov2020-03-301-2/+1
| | | | Needed to add support for nullabiltiy in some places.
* mb_convert_variables(): Make $from an array|string argumentNikita Popov2020-03-301-2/+1
|
* mb_convert_encoding(): Make $input a proper array|string argNikita Popov2020-03-301-2/+1
|
* mb_convert_encoding(): Make $from_encodings a proper array|string argNikita Popov2020-03-301-1/+1
| | | | Switching to FastZPP, as we don't support this in normal zpp.
* Revert "Replace @param annotations with type declarations"Christoph M. Becker2020-02-171-2/+4
| | | | This reverts commit c31029f335ca1b453af799805c43c37e959ad555.
* Replace @param annotations with type declarationsChristoph M. Becker2020-02-161-4/+2
|
* Add union return types for function stubsMáté Kocsis2019-11-111-107/+52
|
* Expect appropriate parameter type in the first placeChristoph M. Becker2019-10-071-2/+2
| | | | | | | | | | | | `mb_encode_numericentity()` and `mb_decode_numericentity()` accepted arbitrary zvals as `$convmap`, but ignored anything else than arrays. This appears to be an unresolved relict of their ZPP conversion for PHP 5.3[1]. We now expect an array in the first place. We also expect `count($convmap)` to be a multiple of four (else we throw a `ValueError`), and do no longer special case empty `$convmap`. [1] <http://git.php.net/?p=php-src.git;a=commit;h=1c77f594294aee9d60e7309279c616c01c39ba9d>
* Add MBString arginfo stubsChristoph M. Becker2019-10-061-0/+179
View Lorry Controller Status