Bug #73921 [Sus]: disable_functions should result in fatal error

Edit report at https://bugs.php.net/bug.php?id=73921&edit=1 ID: 73921 User updated by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: disable_functions should result in fatal error Status: Suspended Type: Bug Package: Scripting Engine problem PHP Version: 7.1.0 Block user comment: N Private report: N New Comment: and when you mean i should create a own error-handler than this would be just pervert when the whole intention of try-catch is to get rid of the expensive function_exists() call which was there in the past and yes a few function_exists() have a visible cost point in xdebug if you know how to develop really fast systems - no idea hwat function_exists does, but feels like in_array() iterating over the complete list Previous Comments: ------------------------------------------------------------------------ [2017-01-13 15:35:33] spam2 at rhsoft dot net > BUT you can't try-catch warnings That's not necessarily correct surely, just try it out, this has changed in PHP7, the code below works perfectly when you don't load pecl-apcu and is much cheaper than function_exists() in case normally the extension is expected to be there and have it not loaded is really the exception i can't see the BC break at all - when someone is calling a function he expects it to be called and on most production servers warnings are nt displayed so he even has no chance to realize why something acts unexpected, with a exception/error it's clear frnakly the whole disable_functions() stuff should be reworked so that it also works PER_DIR and not only global (suhosin in the past had a similar feature and i didn't see the pretended performance impact) try { $cache_entry = apcu_fetch($template_key); if($cache_entry !== false) { return $cache_entry; } } catch(Error $e){} ------------------------------------------------------------------------ [2017-01-13 15:14:58] cmb@php.net Disabling a function isn't the same as undefining it (or never have it being defined, for that matter), as can be seen from get_defined_functions() which also returns disabled functions (by default). Therefore I don't think this qualifies as a bug, but is rather a feature request. However, changing the behavior could cause massive BC break, so this would appear to require the RFC process[1]. Thus I'm suspending this ticket, until someone comes up with an RFC. BTW: the example you're presenting isn't a particular good one, as it would return FALSE regardless of whether disabling popen() would throw an exception or not. > BUT you can't try-catch warnings That's not necessarily correct, see <http://php.net/manual/en/class.errorexception.php#errorexception.examples>. [1] <https://wiki.php.net/rfc/howto> ------------------------------------------------------------------------ [2017-01-12 13:10:05] spam2 at rhsoft dot net Description: ------------ PHP Warning: popen() has been disabled for security reasons sorry, but that is nonsense because from the view of the script it make sno difference if a function can't be called becaus ea typo or because it is disabled and so completly legit code for optional features don't work BUT you can't try-catch warnings private function syslog(string $message) { global $cms_syslog; /** Je nach Serverkonfiguration nicht vorhanden */ try { /** Usernamen hinzufuegen wenn angemeldet */ if(!empty($_SESSION[CMS_HOST_HASH . '_auth_uname'])) { $message .= " ({$_SESSION[CMS_HOST_HASH . '_auth_uname']})"; } /** Sonderzeichen filtern */ $message = strip_tags($this->escape_logitem($message)); /** Kommando mittels "popen" ausfuehren und Rueckgabe in Variable schreiben */ if($fp = popen($cms_syslog . ' ' . escapeshellarg($message) , 'r')) { pclose($fp); return true; } else { return false; } } catch(Error $e) { return false; } } ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=73921&edit=1