3 ms·

One of the biggest improvements is that Libsodium is now built-in. https://dev.to/paragonie/php-72-the-first-programming-language-to-add-modern-cryptography-to-

One of the biggest improvements is that Libsodium is now built-in. https://dev.to/paragonie/php-72-the-first-programming-language-to-add-modern-cryptography-to-its-standard-library https://dev.to/paragonie/php-72-the-first-programming-langua... No more Mcrypt, less cases of having to use OpenSSL and using it wrong. This is a huge security step towards the future.

drostie 9y ago
The other thing is that they have partially fixed the most "wat" bug in PHP: for some arrays that aren't even all that hard to come by when interacting with JS, the following code could change `count($arr)`: foreach ($arr as $key => $val) { $arr[$key] = f($key, $val); } The issue is that `$key` could be a string describing an integer, but `$arr[$key]` will automatically see that you're using a string-int and convert it to an int-int, setting a different key than the internal one. It's only a partial fix but it hits the most common case: you have a JSON payload that happens to have an index of objects which happens to have been given numeric keys: { "abcdef": {"prop1": "hello", "prop2": 123}, "987132": {"prop1": "world", "prop2": 456} } If your framework hands JSON to you as a StdClass object then you would typically convert this to an associative array since that's semantically what it is: as opposed to the internal entities, which in this case appear to be full-fledged objects. (The difference is that the keys of a full-fledged object should be known in advance at a data-schema level and have a control structure of getting/setting `->prop_name`; the keys of a dictionary should be user-settable and have a control structure of `foreach ($dict as $key => $val) {}`.) So the bug still maybe exists in some fringe cases as the underlying cause is not treated, but it is now autofixed by the common idiom of casting `$dict = (array) $params->dict`.
- megous 9y ago
  I would typically write: foreach ($arr as $key => &$val) $val = f($key, $val); This would avoid this issue, while bing simpler.

drostie 9y ago

The other thing is that they have partially fixed the most "wat" bug in PHP: for some arrays that aren't even all that hard to come by when interacting with JS, the following code could change `count($arr)`: foreach ($arr as $key => $val) { $arr[$key] = f($key, $val); } The issue is that `$key` could be a string describing an integer, but `$arr[$key]` will automatically see that you're using a string-int and convert it to an int-int, setting a different key than the internal one. It's only a partial fix but it hits the most common case: you have a JSON payload that happens to have an index of objects which happens to have been given numeric keys: { "abcdef": {"prop1": "hello", "prop2": 123}, "987132": {"prop1": "world", "prop2": 456} } If your framework hands JSON to you as a StdClass object then you would typically convert this to an associative array since that's semantically what it is: as opposed to the internal entities, which in this case appear to be full-fledged objects. (The difference is that the keys of a full-fledged object should be known in advance at a data-schema level and have a control structure of getting/setting `->prop_name`; the keys of a dictionary should be user-settable and have a control structure of `foreach ($dict as $key => $val) {}`.) So the bug still maybe exists in some fringe cases as the underlying cause is not treated, but it is now autofixed by the common idiom of casting `$dict = (array) $params->dict`.

megous 9y ago
I would typically write: foreach ($arr as $key => &$val) $val = f($key, $val); This would avoid this issue, while bing simpler.