[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-doc-bugs
Subject:    [DOC-BUGS] Doc #76995 [Com]: fseek() breaks reading in read/append (a+) mode
From:       "riz dot ali0001 at gmail dot com" <php-bugs () lists ! php ! net>
Date:       2024-01-10 13:52:36
Message-ID: E1rNZ0W-0088Op-2I () bugs ! php ! net
[Download RAW message or body]

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] requinix@php.net

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] requinix@php.net

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

-- 
PHP Documentation Bugs Mailing List (https://www.php.net/)
To unsubscribe, visit: https://www.php.net/unsub.php


[prev in list] [next in list] [prev in thread] [next in thread]