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

go to bug id or search bugs for

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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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 05:01:30 2024 UTC