Following the Specification:
For a text stream, either offset shall be zero, or offset shall be a value returned by an earlier successful call to the ftell function on a stream associated with the same file and whence shall be SEEK_SET.
I understand that offset must be the retun value of a ftell function, or 0, and whence must be SEET_SET (or 0). But I used some integers as offsets and different SEEK_... and it seemed to work well.
For example, these worked:
fseek(file, 4, SEEK_CUR);
fseek(file, -1, SEEK_END);
fseek(file, 0, SEEK_CUR);
When I read the specification it seems to me that it should not work. I tried to use fseek this way many times, and it never failed. Why does it work, what point am I not getting?
Tu.Ma. :
In the ftell documentation you can read\n\n\n For text streams, the numerical value may not be meaningful but can\n still be used to restore the position to the same position later using\n fseek (if there are characters put back using ungetc still pending of\n being read, the behavior is undefined).\n\n\nWhat you cited means that it may have sense to use it if you know where you want to place your pointer at, and you may know it because in precedence you invoked ftell(). \n\nAll your calls to fseek are valid, but in a text file it has not much sense to move using fseek because it is not a random-access (binary) file, but still this does not mean that it is wrong to use it.\n\nFor a text file, you can find here the most common functions to access it, like fscanf(), fprintf() and so on.",
2017-05-09T12:32:40
Klas Lindbäck :
\n When I read the specification it seems to me that it should not work.\n\n\nThe specification, states what must work. It should be seen as the minimum requirements for someone creating a c library (i.e. the implementor of fseek et al). \n\nIncorrect use might still work, but there is no guarantee. The result would depend on the platform.\n\nFor instance, the Linux manual page for fseeksays:\n\n\n The fseek() function sets the file position indicator for the stream pointed to by stream. The new position, measured in bytes, is obtained by adding offset bytes to the position specified by whence. If whence is set to SEEK_SET, SEEK_CUR, or SEEK_END, the offset is relative to the start of the file, the current position indicator, or end-of-file, respectively. A successful call to the fseek() function clears the end-of-file indicator for the stream and undoes any effects of the ungetc(3) function on the same stream.\n\n\nA you can see, the things you tried will work in Linux for both text and binary streams. However, there may exist platforms where fseek won't work with SEEK_CUR or SEEK_END for text streams.\n\nNote also that a stream could be associated with different things: a file, a keyboard, a socket, a terminal window, a device, etc.",
2017-05-09T12:56:09
Paul Ogilvie :
All your fseek calls are valid. The number you provide as the second argument is an offset, meaning it is relative to the seek type that your provide as the third parameter.\n\nfseek(file, 4, SEEK_CUR); // seek 4 bytes forward from current position\nfseek(file, -1, SEEK_END); // seek to 1 byte before the end of the file\nfseek(file, 0, SEEK_CUR); // does nothing.\n\n\nBut see also user Tu.ma's explanation that the seek positions are not accurate and/or can be meaningless if the file has been opened in text mode (especially under Windows because of carriage return/line feed translation).",
2017-05-09T12:56:23
Chris Turner :
There is nothing stopping you using fseek to go beyond the current size of the file. Because doing so allows you to write data at that point, filling the as yet unwritten gap with NULs. Like with this example code - it creates a file with 1000 NULs and then \"hello\\n\"\n\n#include <stdio.h>\n\nint main(void)\n {\n FILE *f;\n\n f=fopen(\"test\",\"w\"); \n if(f)\n {\n fseek(f,1000,SEEK_SET);\n fprintf(f,\"hello\\n\");\n fclose(f);\n }\n else\n {\n perror(\"fopen\");\n }\n }\n",
2017-05-09T12:59:06