On Fr, 2019-03-01 at 18:28 +0100, Nikita Popov wrote:
> made the same mistake there. So there's one more point to add to the
> extension guidelines:
Do we have a persistent space to keep those? The internals manual is
limited ... :-)
> I'm happy to find and fix these bugs, rather than leave the language
> buggy by design ;)
The "old man" in me is skeptical, especially since literally the second
program variation I tried broke in a really subtle way which is hard to
debug and understand for users.
Also I claim that if a string conversion throws an error, it's probably
no good idea to do that conversion in an implicit magic function. (but
yeah, that architectural choice doesn't necessarily have to be a
restriction in the language)
The third thing I tried was around sort(), where we don't have
exception guarantees specified and work on a reference:
<?php
$a = [
'a',
new throws,
'b',
];
try {
sort($a);
} catch (Exception $e) {
}
print_r($a);
?>
results in
Array
(
[0] => a
[1] => b
[2] => throws Object
(
)
)
Thus data is modified, while an exception is thrown. But I believe this
case isn't bad, while I assume there might be other cases, where the
effect has impact. (references should be avoided in idiomatic PHP
anyways ...)
Anyways, to help more productively with your young spirit:
Years back, when we changed string length handling, I created a clang-
analyzer plugin, which checks zend_parse_paramters() calls for the
right type.
https://github.com/johannes/clang-php-checker
I assume it should be possible to create a clang-analyz (or clang-tidy)
check which ensures that conversions are done properly and are checking
for exceptions. This might help third-party extension authors (and if
integrated with the build also long-term ...) with such requirements.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
