php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #80364 Potential issue in ext/standard/user_filters.c: Return Value Not Checked
Submitted: 2020-11-13 17:27 UTC Modified: 2020-11-13 18:14 UTC
From: sagpant at microsoft dot com Assigned:
Status: Duplicate Package: *General Issues
PHP Version: 7.4.12 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sagpant at microsoft dot com
New email:
PHP Version: OS:

 

 [2020-11-13 17:27 UTC] sagpant at microsoft dot com
Description:
------------
In this codebase, you often check the return value of the implicated function when calling it, but in this instance, it appears that you didn’t. Using a consistent return value checking and/or error handling approach can improve code robustness and readability.

File: PHP-7.4.12/ext/standard/user_filters.c
Line Number: 140
Function: call_user_function

Correct reference usage found in main/streams/userspace.c line: 940

Test script:
---------------
Analyzer points out inconsistencies in the code.


Patches

user_filters.patch (last revision 2020-11-13 17:27 UTC by sagpant at microsoft dot com)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-11-13 18:05 UTC] requinix@php.net
-Status: Open +Status: Duplicate
 [2020-11-13 18:05 UTC] requinix@php.net
Judging by bug #80284 and the commentary on
  https://github.com/php/php-src/pull/6412
this is either not a bug (call_user_function is invoking a function which returns void from within a destructor) or a duplicate (per @cmb's "I think we should at least document..." comment).
 [2020-11-13 18:14 UTC] sagpant at microsoft dot com
If this is not a bug then yes we can ignore it altogether.
But if this is a bug (per @cmb's comment), then we should also address this instance of the function call. 
Infact, our analyzer has found 5 other instance (including this) of this function call which have similar issues? Should all those be included under the same PR too?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 04:01:29 2024 UTC