php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #73810 hex2bin should return false or throw an exception instead of an E_WARNING
Submitted: 2016-12-24 15:05 UTC Modified: 2021-08-16 15:02 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: francesco dot montanari at outlook dot com Assigned: cmb (profile)
Status: Wont fix Package: Strings related
PHP Version: 7.1.0 OS: All
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: francesco dot montanari at outlook dot com
New email:
PHP Version: OS:

 

 [2016-12-24 15:05 UTC] francesco dot montanari at outlook dot com 
Description:
------------
I agree with this thread: http://grokbase.com/t/php/php-internals/136tjmm93r/hex2bin-e-warning-is-too-much-for-odd-string
"a function that is supposed to deal with external inputs is better if it returns FALSE without error"

Now we have to do something like this:

$binaryUuid = @hex2bin(str_replace('-', '', $_GET['uuid']));
if($binaryUuid === false) {
    // Show an "Invalid UUID" error
}

but using the "@" operator is considered bad practice, and validate the input BEFORE passing it to hex2bin is out of discussion because it will slow down the app for nothing (for example I receive 10 million valid uuid per day, and only about a hundred invalid ones).

Returning false, or throwing a catchable exception would be a better behaviour

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-25 23:45 UTC] yohgaki@php.net 
Exceptions are preferred, but exception adoption should be done with consistency. i.e. All standard module features should adopt exception at least.

For the time being, use ErrorException with your error handler.

http://php.net/manual/en/errorexception.construct.php

i.e. Throw ErrorException from your error handler to convert errors to exceptions.
 [2016-12-27 13:55 UTC] cmb@php.net
-Package: Unknown/Other Function +Package: Strings related
 [2021-08-16 15:02 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-08-16 15:02 UTC] cmb@php.net 
There is no way to change a function to suddenly throw instead of
of raising a warning; except maybe in a major version, but that
still requires an RFC.  And, like Yasuo already said, this
shouldn't be done for a single function.  Thus, I'm closing this
ticket as WONTFIX.  If you are still interested in this, please
pursue the RFC process[1].

Also note that this particular case might better be addressed by
using the PECL/uuid package[2].

[1] <https://wiki.php.net/rfc/howto>
[2] <https://pecl.php.net/package/uuid>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun May 05 04:01:32 2024 UTC