Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

issue 324: change parameter name from options to flags #376

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion generated/functionsList.php
Original file line number Diff line number Diff line change
Expand Up @@ -674,7 +674,6 @@
'openssl_private_encrypt',
'openssl_public_decrypt',
'openssl_public_encrypt',
'openssl_random_pseudo_bytes',
'openssl_seal',
'openssl_sign',
'openssl_spki_export',
Expand Down
28 changes: 0 additions & 28 deletions generated/openssl.php
Original file line number Diff line number Diff line change
Expand Up @@ -1159,34 +1159,6 @@ function openssl_public_encrypt(string $data, ?string &$encrypted_data, $public_
}


/**
* Generates a string of pseudo-random bytes, with the number of bytes
* determined by the length parameter.
*
* It also indicates if a cryptographically strong algorithm was used to produce the
* pseudo-random bytes, and does this via the optional strong_result
* parameter. It's rare for this to be FALSE, but some systems may be broken or old.
*
* @param int $length The length of the desired string of bytes. Must be a positive integer. PHP will
* try to cast this parameter to a non-null integer to use it.
* @param bool|null $strong_result If passed into the function, this will hold a bool value that determines
* if the algorithm used was "cryptographically strong", e.g., safe for usage with GPG,
* passwords, etc. TRUE if it did, otherwise FALSE
* @return string Returns the generated string of bytes on success.
* @throws OpensslException
*
*/
function openssl_random_pseudo_bytes(int $length, ?bool &$strong_result = null): string

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just ran into this breaking change when upgrading safe. Shouldn't this method have been moved to the deprecated space instead of just being removed? As i randomly ran into an error after doing a minor update, without a deprecation notice prior.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm up for making a PR is that is preferable btw

{
error_clear_last();
$result = \openssl_random_pseudo_bytes($length, $strong_result);
if ($result === false) {
throw OpensslException::createFromPhpError();
}
return $result;
}


/**
* openssl_seal seals (encrypts)
* data by using the given cipher_algo with a randomly generated
Expand Down
6 changes: 3 additions & 3 deletions lib/special_cases.php
Original file line number Diff line number Diff line change
Expand Up @@ -27,15 +27,15 @@
* @param bool $assoc When true, returned objects will be converted
* into associative arrays.
* @param int<1, max> $depth User specified recursion depth.
* @param int $options Bitmask of JSON decode options.
* @param int $flags Bitmask of JSON decode options.
*
* @return mixed
* @throws JsonException if the JSON cannot be decoded.
* @link http://www.php.net/manual/en/function.json-decode.php
*/
function json_decode(string $json, bool $assoc = false, int $depth = 512, int $options = 0)
function json_decode(string $json, bool $assoc = false, int $depth = 512, int $flags = 0): mixed
Copy link

@shadowhand shadowhand Aug 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just as a note, this could be considered a breaking change in PHP 8.x because anyone using the named argument will be faced with a breaking change in a bugfix package release.

EDIT: I see this was reported above. I feel pretty strongly about this issue, especially for this package which aims to have parity with PHP functions of the same name. I am 100% for ensuring that this package stays in alignment with PHP current in terms of parameter names. However, I also think there is very little cost to publishing a new minor, or even major, release when parameter names change. If this change had bumped to 2.3.0 instead of 2.2.3, would anything bad have happened? I doubt it.

{
$data = \json_decode($json, $assoc, $depth, $options);
$data = \json_decode($json, $assoc, $depth, $flags);
if (JSON_ERROR_NONE !== json_last_error()) {
throw JsonException::createFromPhpError();
}
Expand Down
1 change: 0 additions & 1 deletion rector-migrate.php
Original file line number Diff line number Diff line change
Expand Up @@ -684,7 +684,6 @@
'openssl_private_encrypt' => 'Safe\openssl_private_encrypt',
'openssl_public_decrypt' => 'Safe\openssl_public_decrypt',
'openssl_public_encrypt' => 'Safe\openssl_public_encrypt',
'openssl_random_pseudo_bytes' => 'Safe\openssl_random_pseudo_bytes',
'openssl_seal' => 'Safe\openssl_seal',
'openssl_sign' => 'Safe\openssl_sign',
'openssl_spki_export' => 'Safe\openssl_spki_export',
Expand Down