You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ff_fseek has important restrictions that are not mentioned. Since this behavior is non-standard, I believe it would be best to state the restrictions rather than leave them unsaid. They might come as a surprise to someone used to, say, POSIX.
According to The Open Group Base Specifications, fseek , “The fseek() function shall allow the file-position indicator to be set beyond the end of existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap.”
However, in +FAT, if you try to ff_fseek past the end of existing data in the file you will get an Illegal seek (29) error.
According to The Open Group Base Specifications, fseek , "The fseek() function shall set the file-position indicator for the stream pointed to by stream... The new position, measured in bytes from the beginning of the file, shall be obtained by adding offset to the position specified by whence. The specified point is the beginning of the file for SEEK_SET, the current value of the file-position indicator for SEEK_CUR, or end-of-file for SEEK_END."
However, if a file is opened for append (ff_fopen pcMode "a" or "a+") and the file already exists, +FAT defines "The beginning of the file" to be the end of the preexisting file. Therefore it is impossible to ff_fseek or ff_rewind to the absolute beginning of the file or to any position between there and the end of the preexisting file.
ff_rewind says it "Moves the current read/write position back to the start of a file." It should be clarified that if the file is opened for append with ff_fopen or ff_truncate the "start of a file" is considered to be the end of any preexisting file.
The GNU C Library Reference Manual says this about file position: "Streams and descriptors that are opened for append access are treated specially for output: output to such files is always appended sequentially to the end of the file, regardless of the file position. However, the file position is still used to control where in the file reading is done."
Reference
Please attach the URL at which you are experiencing the issue.
Describe the issue
ff_fseek has important restrictions that are not mentioned. Since this behavior is non-standard, I believe it would be best to state the restrictions rather than leave them unsaid. They might come as a surprise to someone used to, say, POSIX.
According to The Open Group Base Specifications, fseek , “The fseek() function shall allow the file-position indicator to be set beyond the end of existing data in the file. If data is later written at this point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap.”
However, in +FAT, if you try to ff_fseek past the end of existing data in the file you will get an Illegal seek (29) error.
According to The Open Group Base Specifications, fseek , "The fseek() function shall set the file-position indicator for the stream pointed to by stream... The new position, measured in bytes from the beginning of the file, shall be obtained by adding offset to the position specified by whence. The specified point is the beginning of the file for SEEK_SET, the current value of the file-position indicator for SEEK_CUR, or end-of-file for SEEK_END."
However, if a file is opened for append (ff_fopen pcMode "a" or "a+") and the file already exists, +FAT defines "The beginning of the file" to be the end of the preexisting file. Therefore it is impossible to ff_fseek or ff_rewind to the absolute beginning of the file or to any position between there and the end of the preexisting file.
ff_rewind says it "Moves the current read/write position back to the start of a file." It should be clarified that if the file is opened for append with ff_fopen or ff_truncate the "start of a file" is considered to be the end of any preexisting file.
The GNU C Library Reference Manual says this about file position: "Streams and descriptors that are opened for append access are treated specially for output: output to such files is always appended sequentially to the end of the file, regardless of the file position. However, the file position is still used to control where in the file reading is done."
Reference
Please attach the URL at which you are experiencing the issue.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fseek.html
https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_FAT/stdio_API/ff_rewind.html
Screenshot
If applicable, please attach screenshot.
Browser
The text was updated successfully, but these errors were encountered: