php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #78104 Return section for readgzfile informs about @ operator
Submitted: 2019-06-04 14:53 UTC Modified: 2019-06-08 15:43 UTC
From: girgias@php.net Assigned: girgias (profile)
Status: Closed Package: Zlib related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
17 + 24 = ?
Subscribe to this entry?

 
 [2019-06-04 14:53 UTC] girgias@php.net
Description:
------------
---
From manual page: https://php.net/function.readgzfile
---

The Return value sections say this:
"If an error occurs, FALSE is returned and unless the function was called as @readgzfile, an error message is printed."

Which seems odd to describe the behavior of the error suppression operator.
Should it be removed/rewritten?


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-06-04 14:58 UTC] daverandom@php.net
The information about the fact that the function may emit an error should be moved to an Errors/Exceptions section (like e.g. https://www.php.net/manual/en/function.fopen.php)

The mention of the error suppression operator seems a little odd to me, however it is mentioned on the fopen() page linked above so I'm not actually sure there.
 [2019-06-04 15:12 UTC] girgias@php.net
Huh, indeed it is mentioned in fopen, maybe @salathe could chime in as the Editor?

Will just need to figure out what kind of error readgzfile produces before being able to update its doc page.
 [2019-06-04 18:45 UTC] salathe@php.net
> Should it be removed/rewritten?

Yes.  It looks like this was copied from the readfile() page.  Similar text appears for a small handful of other functions [1], which should also be tidied up.

Chris is also right in mentioning that errors belong in the "Errors/Exceptions" section.

> Will just need to figure out what kind of error readgzfile produces before being able to update its doc page.

Looks like E_WARNING to me.


[1] From a quick search: opendir(), fopen(), readfile(), mysql_connect(), and mysql_pconnect().
 [2019-06-04 18:58 UTC] girgias@php.net
Okay, do you want me to fix all the relevant functions by attaching them to this bug report?

Also, it seems like a lot of manual pages use the return section to showcase errors with false returns.

Does readfile also generate an E_WARNING?
 [2019-06-08 15:41 UTC] girgias@php.net
Automatic comment from SVN on behalf of girgias
Revision: http://svn.php.net/viewvc/?view=revision&revision=347576
Log: Fix Doc Bug #78104 by removing mentions of @ operator and moving E_WARNING info into Error/Exception section.
 [2019-06-08 15:43 UTC] girgias@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: girgias
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 19:01:33 2024 UTC