forrest@LBL.GOV (01/27/88)
The following program shows a bug in the ftell/fseek
routines. I reread the documentation on these routines
to make sure what I'm doing is correct and it is.
What I'm doing is reading records from a file. If I use
ftell to tell me where a certain record is located and then
use fseek to go back to the record, I find that the next
record differs depending on if the input file is a
stream or a variable record file. Note that I am using
ftell/fseek at a record boundary, as mentioned in the
documentation.
---------------------------------------------------
#include stdio
#include string
char in_line[128];
main()
{
FILE *ifp;
int start_pos;
ifp = fopen("testdata","r");
fgets(in_line, sizeof in_line, ifp); /* should read line 1 */
fgets(in_line, sizeof in_line, ifp); /* should read line 2 */
start_pos = ftell(ifp); /* current pos is start of line 3 */
fgets(in_line, sizeof in_line, ifp); /* should read line 3 */
fseek(ifp, start_pos, 0); /* go back to line 3 */
fgets(in_line, sizeof in_line, ifp); /* read unknown line */
printf("Read - %s",in_line);
fclose (ifp);
}
------------------------------------------------------
Assume the following input file:
-------------------------------------------------------
This is line 11111111111111
This is line 222222222222222
This is line 333333333333333
This is line 444444444444444
This is line 555555555555555
-----------------------------
When the input file is a stream record file the program says that
it read the third line. But, when the input is a variable record file
the programs says it read the second line.
I thought that one of the advantages of RMS is that all access methods
have the same results even if the record type varies. Even given the
requirement that fseek/ftell only work at record boundaries, this
program shows that this isn't the case. Furthermore, it means that
porting programs from Unix or MS-DOS is made even more difficult.
Comments?
Jon Forrest
FORREST@LBL.GOV (internet)
FORREST@LBL (bitnet)
-------scjones@sdrc.UUCP (Larry Jones) (02/10/88)
In article <880126085340.21e04d69@Csa2.LBL.Gov>, forrest@LBL.GOV writes: > > What I'm doing is reading records from a file. If I use > ftell to tell me where a certain record is located and then > use fseek to go back to the record, I find that the next > record differs depending on if the input file is a > stream or a variable record file. I too have had this problem from day 1 with VAX C. The problem seems to be that ftell on a record file just gets the current record number out of the FAB (or RAB, or whereever the heck RMS keeps it). Unfortunately, you aren't actually in a record until you read at least one character from it, so the "official" method of using fgets() doesn't help at all - you still haven't read any of the next record so you still get the previous one. As fas as suggestions, I have but two, neither of which is particularly nice: 1) Don't use record files. 2) Do un ungetc(getc(file), file); just before the ftell(). -- ---- Larry Jones UUCP: uunet!sdrc!scjones SDRC MAIL: 2000 Eastman Dr., Milford, OH 45150 AT&T: (513) 576-2070 "When all else fails, read the directions."
jdc@naucse.UUCP (02/10/88)
In article <880126085340.21e04d69@Csa2.LBL.Gov>, forrest@LBL.GOV writes: > The following program shows a bug in the ftell/fseek > > When the input file is a stream record file the program says that > it read the third line. But, when the input is a variable record file > the programs says it read the second line. > I put an SPR together 2 years ago on this bug. I wasn't on maintenance at the time and it was kicked back. Since then I've submitted another and it seems to have been lost. Now I'm submitting it again. I feel a little guilty (like if I'd been a bit more squeaky maybe it would be fixed by now). In the meantime, I've "worked around" the bug with crazy kludges and cursed the support people. PLEASE SUBMIT AN SPR! Maybe if they get more than one complaint they'll listen. (When this is fixed I'll have a bunch of *broken* code to fix :-) Anyway, my sympathies--your bug is real. (I suspect they relied too heavily on RMS in their implementation...) -- John Campbell ...!arizona!naucse!jdc unix? Sure send me a dozen, all different colors.