Doc #76995 [Com]: fseek() breaks reading in read/append (a+) mode

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

 ID:                 76995
 Comment by:         riz dot ali0001 at gmail dot com
 Reported by:        miloslav dot hula at gmail dot com
 Summary:            fseek() breaks reading in read/append (a+) mode
 Status:             Open
 Type:               Documentation Problem
 Package:            Streams related
 PHP Version:        7.3.0RC2
 Block user comment: N
 Private report:     N

 New Comment:

The issue highlighted in the test script relates to the use of fseek() in 'a+' mode, which appears to disrupt content reading. This seems to stem from conflicting information in the documentation. While the fopen() documentation indicates that fseek() can be used in 'a+' mode to adjust the reading position (with writes always being appended), the fseek() documentation contradicts this by stating that using fseek() in append mode ('a' or 'a+') can lead to undefined behavior. This discrepancy suggests a need for clarification in the documentation to ensure proper usage and avoid potential
 issues in file handling


Previous Comments:
------------------------------------------------------------------------
[2023-12-10 04:21:24] sincerelyjulie0 at gmail dot com

position the file pointer for reading.

------------------------------------------------------------------------
[2023-05-13 12:02:14] cynthiamarshal0010 at gmail dot com

To address the doc bug where fseek() breaks reading in read/append (a+) mode, it's important to understand the behavior of fseek() in that mode and how to correctly position the file pointer for reading. Here's an explanation and solution to update the documentation:

Explanation:
In the a+ mode, when you use fseek() with a positive offset, it is expected to move the file pointer to that offset from the beginning of the file. However, in certain implementations, fseek() may not work as expected in a+ mode and instead positions the file pointer relative to the current end of the file. This behavior can lead to unexpected results when trying to read from the file.

Solution:
To correctly position the file pointer for reading in a+ mode, you should use fseek() with a negative offset relative to the end of the file. Here's an example of how to update the documentation to reflect this:

vbnet

When using `fseek()` in read/append (`a+`) mode, it's important to note that its behavior may vary depending on the implementation. In some cases, `fseek()` may not correctly position the file pointer for reading. To ensure proper positioning, follow the recommended approach below:

To move the file pointer to a specific position from the end of the file, use a negative offset with `fseek()`. For example, to move the file pointer to the last 100 bytes of the file:

   fseek(file, -100, SEEK_END);

This ensures that the file pointer is correctly positioned for subsequent read operations.

Please note that this workaround may not be necessary in all implementations of the C standard library. It's recommended to test and verify the behavior of `fseek()` in your specific environment to ensure compatibility and consistent results.

By providing this updated information, users will be informed about the potential issue with fseek() in a+ mode and the recommended approach to correctly position the file pointer for reading. (https://dgmeportal.live/)github.com

------------------------------------------------------------------------
[2018-10-10 16:08:23] [email protected]

And seconds after I hit Submit, I realize that documenting append mode's fseek quirks would be a good idea.

------------------------------------------------------------------------
[2018-10-10 16:07:12] [email protected]

Unfortunately this really is one of those "undefined behavior" situations, and PHP isn't the one responsible for it.

Look at the fopen(3) docs on Linux: https://linux.die.net/man/3/fopen
> Reads and writes may be intermixed on read/write streams in any order. Note
> that ANSI C requires that a file positioning function intervene between output
> and input, unless an input operation encounters end-of-file. (If this condition
> is not met, then a read is allowed to return the result of writes other than
> the most recent.) Therefore it is good practice (and indeed sometimes necessary
> under Linux) to put an fseek(3) or fgetpos(3) operation between write and read
> operations on such a stream. This operation may be an apparent no-op (as in
> fseek(..., 0L, SEEK_CUR) called for its synchronizing side effect.

------------------------------------------------------------------------
[2018-10-10 15:11:26] miloslav dot hula at gmail dot com

Or: "In this mode, fseek() only affects the reading position". Sound like positive claim.

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


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=76995


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