php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #65116 fgets() fails to return newline at end of string
Submitted: 2013-06-25 04:10 UTC Modified: 2013-06-25 18:43 UTC
From: strideroflands at yahoo dot com Assigned: ab (profile)
Status: Not a bug Package: Streams related
PHP Version: 5.4.16 OS: Windows
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: strideroflands at yahoo dot com
New email:
PHP Version: OS:

 

 [2013-06-25 04:10 UTC] strideroflands at yahoo dot com
Description:
------------
---
From manual page: http://www.php.net/function.fgets
---

In "C" programming, the function fgets() returns the end of line character at the end of the string.  The description of stream_get_line says

"This function is nearly identical to fgets() except in that it allows end of line delimiters other than the standard \n, \r, and \r\n, and does not return the delimiter itself."

This suggests that fgets() should indeed return a newline character.  Such functionality would be very useful.  In "C", fgets(fp) is known to be a known source of bugs, since it overwrites memory buffers when the line is longer than intended.  In PHP, fgets() allows an additional parameter to limit the size of a buffer it can fill.  If fgets() does not return a newline if it reaches one, how are we supposed to know if it reached the end of the "length" parameter, or if it reached a newline?

In the test script, it can report if a line is longer than expected only if the newline is returned.  However, this does not happen.  The only way to know if this happened would be 1) write your own fgets() function, 2) see if you are at the end of the file, use ftell to determine the position, read a byte, seek to the position ftell just reported, and test on the byte.  This is more laborious than the simple test for a newline below.  The lack of returning the newline effectively obviates the usefulness of the "length" parameter.  If one were to encounter a large video file, e.g., the whole thing might be read into memory, and there would be no convenient way to detect it.

I generally detest any changes that break existing code by changing the language.  Therefore, I suggest making another function that won't be giving existing applications newline characters they didn't have before; or else having a variable that you set to make fgets() return newlines like it should.

This is actually vers. 5.4.15.

Test script:
---------------
$hndl = fopen("aFileWithNewlines.txt", "r+");
$line= fgets ($hndl,80);
if (strpos($line,"\n")==false)
    echo "error";
else
    echo "no error";


Expected result:
----------------
"error" if the line is longer than 80 characters, otherwise, "no error".

Actual result:
--------------
always "error"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-25 06:40 UTC] strideroflands at yahoo dot com
sorry.  it is keeping the newline as expected after all.  please delete this bug.
 [2013-06-25 07:53 UTC] ab@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: ab
 [2013-06-25 18:43 UTC] sixd@php.net
-Status: Closed +Status: Not a bug
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 19:01:28 2024 UTC