fseek/fsetpos moving stream position incorrectly

[dfelikson]

I have a simple piece of code that ftell's me the position after
reading the first line of a file, then reads two more lines, then
fseek's back to the position, and reads the next line. What I want it
to do is read the second line of the file, however, for some reason,
it grabs the third line. I get similar results with fgetpos and
fsetpos.

Is there something simple I'm missing here? My code is below:

/
******************************************************************************************************
// Scan first line
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f\n",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );
printf("%d %f\n",file_sec,el);

// Get position
//fgetpos( SA_file, &pos );
position = ftell( SA_file );

// Scan 2 more lines
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f\n",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );
printf("%d %f\n",file_sec,el);
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f\n",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );
printf("%d %f\n",file_sec,el);

// Go to position
//fsetpos( SA_file, &pos );
fseek( SA_file, position, SEEK_SET );

// Scan second line
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );
printf("%d %f\n",file_sec,el);
/
******************************************************************************************************

Thanks!

 

[santosh]

I have a simple piece of code that ftell's me the position after
reading the first line of a file, then reads two more lines, then
fseek's back to the position, and reads the next line. What I want it
to do is read the second line of the file, however, for some reason,
it grabs the third line. I get similar results with fgetpos and
fsetpos.

Is there something simple I'm missing here? My code is below:

/************************************************************************/
// Scan first line
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f\n",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );

Does this call actually succeed? Also note that the 'f' format specifier
is for float and 'lf' is for double.

printf("%d %f\n",file_sec,el);

// Get position
//fgetpos( SA_file, &pos );
position = ftell( SA_file );

Does this also succeed?

// Scan 2 more lines
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f\n",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );
printf("%d %f\n",file_sec,el);
j = fscanf( SA_file, "\"%4d/%2d/%2d %2d:%2d:%2d.%3d\"\t%f\t%f\t%f\n",
&file_yr, &file_mon, &file_day, &file_hr, &file_min, &file_sec,
&file_msec, &range, &az, &el );
printf("%d %f\n",file_sec,el);

// Go to position
//fsetpos( SA_file, &pos );
fseek( SA_file, position, SEEK_SET );

Does this call succeed, i.e., return zero.

 

[dfelikson]

Both of those calls succeed. As it turned out, the file I was parsing
was created in a Unix environment. Thus, it had only one "newline"
character as opposed to a standard Windows text file which has two
"newline" characters (\r\n in Windows). What was happening was that
my code was overrunning the end of one line by one character because
it was expecting two "newline" characters to be there when there was
really only one.

To fix this, I had to open the file using the fopen function with an
"rb" parameter (b for binary file).

 

[Kenneth Brody]

Both of those calls succeed. As it turned out, the file I was parsing
was created in a Unix environment. Thus, it had only one "newline"
character as opposed to a standard Windows text file which has two
"newline" characters (\r\n in Windows). What was happening was that
my code was overrunning the end of one line by one character because
it was expecting two "newline" characters to be there when there was
really only one.

To fix this, I had to open the file using the fopen function with an
"rb" parameter (b for binary file).

I ran into this myself once.

Am I correct in assuming that opening a file in text mode which
doesn't fit the O/S's definition of "text file" invokes UB? Or
would this be considered a "quirk"/"bug" in the MSVC runtime
library? (Basically, when a stream opened in text mode contains
'\n' in the input buffer, ftell assumes that two characters were
actually read from the file.)

Another "quirk" in the MSVC library is opening a file in text mode
which contains Ctrl-Z (0x1a) as the last character in the file. In
that case, fopen will shrink the file by one character. If the
file really is text, this can be considered "good", in that it gets
rid of the legacy EOF marker and allows append mode to work as
expected. However, if the file is binary, "bad things" can happen.

However, I would not be surprised to discover that opening a non-
text file in text mode invokes UB, and these are all legitimate
behaviors as far as the standard is concerned.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[David Thompson]

On Mon, 29 Oct 2007 10:57:36 -0400, Kenneth Brody

Am I correct in assuming that opening a file in text mode which
doesn't fit the O/S's definition of "text file" invokes UB? Or
would this be considered a "quirk"/"bug" in the MSVC runtime
library? <snip>

It is certainly implementation-dependent; historically files (or
rather things accessible as files) and filesystems have been one of
the areas of greater (greatest?) variation across systems. This is
somewhat masked today by the overwhelming prevalence of two OS
families (no longer even arguably three) with similar file semantics.

7.19.3p8 does say "The rules for composing valid file names are
implementation-defined." It could be argued this requires the
implementation to _document_ what types and formats of files are
supported (correctly) and I have seen some do so. I have no idea if
MSVC (or rather some relevant version(s) of MSVC) does, and it's not
worth spending my time to search for it. If it doesn't, you could
argue this is at least a doc bug if not a 'real' bug. Good luck.

- formerly david.thompson1 || achar(64) || worldnet.att.net