Bug #65116 [Com]: fgets() fails to return newline at end of string

From: Date: Tue, 25 Jun 2013 06:40:43 +0000
Subject: Bug #65116 [Com]: fgets() fails to return newline at end of string
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-179783@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=65116&edit=1

 ID:                 65116
 Comment by:         strideroflands at yahoo dot com
 Reported by:        strideroflands at yahoo dot com
 Summary:            fgets() fails to return newline at end of string
 Status:             Open
 Type:               Bug
 Package:            Streams related
 Operating System:   Windows
 PHP Version:        5.4.16
 Block user comment: N
 Private report:     N

 New Comment:

sorry.  it is keeping the newline as expected after all.  please delete this bug.


Previous Comments:
------------------------------------------------------------------------
[2013-06-25 04:10:16] 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"


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=65116&edit=1


Thread (4 messages)

« previous php.bugs (#179783) next »