|  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: 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:
Solve the problem:
18 + 11 = ?
Subscribe to this entry?

 [2019-06-04 14:53 UTC]
From manual page:

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?


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-06-04 14:58 UTC]
The information about the fact that the function may emit an error should be moved to an Errors/Exceptions section (like e.g.

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]
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]
> 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]
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]
Automatic comment from SVN on behalf of girgias
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]
-Status: Open +Status: Closed -Assigned To: +Assigned To: girgias
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 06:01:30 2024 UTC