On Thu, 17 Sep 2020 at 14:53, Côme Chilliet < come.chill...@fusiondirectory.org> wrote:
> Hello, > > After playing with phpstan and seeing their stubs for some LDAP functions > were > wrong, I noticed that documentation for LDAP functions and stubs in > ext/ldap/ldap.stub.php differs. > A lot of the documentation is not up to date and will needs to be updated after there has been a check of the argument names for consistency with other extensions in regards to named params, the stubs are the source of trust. > Especially in a lot of functions, the documentation states "string $dn = > NULL" > but the stub states non-nullable string parameter. Also, the ldap.stub.php > file contains a lot of "string $bind_rdn = UNKNOWN" in places where the > documentations states = NULL. What does UNKOWN mean here? > UNKNOWN means that the default value cannot be specified due to some reason mostly the case for arguments passed by references or funcky function signature implementation which check the number of argument passed to the function. > I would like to fix those conflicts. > Basically my questions are: > 1) What is the difference between s and S in zend_parse_parameters and how > do > they behave for a NULL value? > None in regards to userland as 's' is a char* followed by a size_t ad 'S' is a zend_string. As for all internal functions which are not nullable they will coerce null to the respective type so for a string argument null would become an empty string. > 2) What would changing = UNKNOWN to = NULL impact? Explicit support for nullable types in the C implementation > 3) When a function like ldap_bind is called, is calling ldap_bind($link), > and > ldap_bind($link, NULL) changing anything else than ZEND_NUM_ARGS? > This relates to point 1 and 2 above, if there is no support for nullable types passing null can change the meaning of it. Côme > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Hope this answers most of the questions Best regards George P. Banyard
