VC, fscanf and LF

fscanf and LF

Author	Message
gordon smit #1 / 6	fscanf and LF I have a question about fscanf using the MS C++ compiler version 12.00.8804 for 80x86 and the corresponding library. We have source that we trust functions properly in Unix, but we are now compiling a console application in Visual C++ and have a one byte file position error involving fscanf. We have a file as follows: File pos. Char. ---- -------- 286: 0x36 = '6' 287: 0x35 = '5' 288: 0x35 = '5' 289: 0x33 = '3' 290: 0x36 = '6' 291: 0x20 = ' ' 292: 0x33 = '3' 293: 0x36 = '6' 294: 0x0a = <LF> 295: 0x00 (data begins here) 296: 0x00 297: 0xab 298: 0xfd At the start, the position in the file is at 286. The original source uses this statement: fscanf( fpData, "%d %d\n", &num0, &num1 ); which leaves the file position at 296. This appears to be incorrect. It correctly returns 2 as the number of items read. We can use the following statement: fscanf( fpData, "%d %d%c", &num0, &num1, &ch ); which leaves the position at 295, as we expect. Is the behaviour of the first statement a defect? If so, is there a source of information or a fix available? Thanks, Gordon Smith
Mon, 21 Feb 2005 02:37:42 GMT

David Crow [MCSD #2 / 6	fscanf and LF Are you opening the file as text or binary? Quote: > I have a question about fscanf using the MS C++ compiler > version 12.00.8804 for 80x86 and the corresponding library. > We have source that we trust functions properly in Unix, > but we are now compiling a console application in Visual > C++ and have a one byte file position error involving > fscanf. > We have a file as follows: > File > pos. Char. > ---- -------- > 286: 0x36 = '6' > 287: 0x35 = '5' > 288: 0x35 = '5' > 289: 0x33 = '3' > 290: 0x36 = '6' > 291: 0x20 = ' ' > 292: 0x33 = '3' > 293: 0x36 = '6' > 294: 0x0a = <LF> > 295: 0x00 (data begins here) > 296: 0x00 > 297: 0xab > 298: 0xfd > At the start, the position in the file is at 286. > The original source uses this statement: > fscanf( fpData, "%d %d\n", &num0, &num1 ); > which leaves the file position at 296. This appears to be > incorrect. It correctly returns 2 as the number of items > read. > We can use the following statement: > fscanf( fpData, "%d %d%c", &num0, &num1, &ch ); > which leaves the position at 295, as we expect. > Is the behaviour of the first statement a defect? If so, > is there a source of information or a fix available? > Thanks, > Gordon Smith
Mon, 21 Feb 2005 04:23:48 GMT

gordon smit #3 / 6	fscanf and LF Binary fopen with "rb". Quote: >-----Original Message----- >Are you opening the file as text or binary? >> I have a question about fscanf using the MS C++ compiler >> version 12.00.8804 for 80x86 and the corresponding library. >> We have source that we trust functions properly in Unix, >> but we are now compiling a console application in Visual >> C++ and have a one byte file position error involving >> fscanf. >> We have a file as follows: >> File >> pos. Char. >> ---- -------- >> 286: 0x36 = '6' >> 287: 0x35 = '5' >> 288: 0x35 = '5' >> 289: 0x33 = '3' >> 290: 0x36 = '6' >> 291: 0x20 = ' ' >> 292: 0x33 = '3' >> 293: 0x36 = '6' >> 294: 0x0a = <LF> >> 295: 0x00 (data begins here) >> 296: 0x00 >> 297: 0xab >> 298: 0xfd >> At the start, the position in the file is at 286. >> The original source uses this statement: >> fscanf( fpData, "%d %d\n", &num0, &num1 ); >> which leaves the file position at 296. This appears to be >> incorrect. It correctly returns 2 as the number of items >> read. >> We can use the following statement: >> fscanf( fpData, "%d %d%c", &num0, &num1, &ch ); >> which leaves the position at 295, as we expect. >> Is the behaviour of the first statement a defect? If so, >> is there a source of information or a fix available? >> Thanks, >> Gordon Smith >.
Mon, 21 Feb 2005 05:06:59 GMT

Alf E. Helset #4 / 6	fscanf and LF Quote: > I have a question about fscanf using the MS C++ compiler > version 12.00.8804 for 80x86 and the corresponding library. > We have source that we trust functions properly in Unix, > but we are now compiling a console application in Visual > C++ and have a one byte file position error involving > fscanf. > We have a file as follows: > File > pos. Char. > ---- -------- > 286: 0x36 = '6' > 287: 0x35 = '5' > 288: 0x35 = '5' > 289: 0x33 = '3' > 290: 0x36 = '6' > 291: 0x20 = ' ' > 292: 0x33 = '3' > 293: 0x36 = '6' > 294: 0x0a = <LF> > 295: 0x00 (data begins here) > 296: 0x00 > 297: 0xab > 298: 0xfd > At the start, the position in the file is at 286. > The original source uses this statement: > fscanf( fpData, "%d %d\n", &num0, &num1 ); > which leaves the file position at 296. This appears to be > incorrect. It correctly returns 2 as the number of items > read. > We can use the following statement: > fscanf( fpData, "%d %d%c", &num0, &num1, &ch ); > which leaves the position at 295, as we expect. > Is the behaviour of the first statement a defect? If so, > is there a source of information or a fix available? > Thanks, > Gordon Smith The problem probably relates to the difference in handling "newline" different in unix and windows/dos. The text "%d %d\n" translates to "%d %d\012" on unix, but "%d %d\015\012" (CR+LF) on windows. I think you ask for problems using "textfile functions" (fscanf("\n")) on a binary file in cross-plattform code. If the file was either text or binary this would probably work if you use the related binary flag to fopen(), but this seems to be a mix... -Alf
Mon, 21 Feb 2005 14:52:54 GMT

Igor Tandetni #5 / 6	fscanf and LF Nonsense. strlen("\n") == 1, on Windows or otherwise. \n to CRLF translation only happens when \n is written to a file in text mode. -- With best wishes, Igor Tandetnik "For every complex problem, there is a solution that is simple, neat, and wrong." H.L. Mencken Quote: > The problem probably relates to the difference in handling "newline" > different in unix and windows/dos. > The text "%d %d\n" translates to "%d %d\012" on unix, but "%d > %d\015\012" (CR+LF) on windows.
Mon, 21 Feb 2005 22:12:15 GMT

Barry Schwar #6 / 6	fscanf and LF On Wed, 4 Sep 2002 11:37:42 -0700, "gordon smith" Quote: >I have a question about fscanf using the MS C++ compiler >version 12.00.8804 for 80x86 and the corresponding library. >We have source that we trust functions properly in Unix, >but we are now compiling a console application in Visual >C++ and have a one byte file position error involving >fscanf. >We have a file as follows: >File >pos. Char. >---- -------- >286: 0x36 = '6' >287: 0x35 = '5' >288: 0x35 = '5' >289: 0x33 = '3' >290: 0x36 = '6' >291: 0x20 = ' ' >292: 0x33 = '3' >293: 0x36 = '6' >294: 0x0a = <LF> >295: 0x00 (data begins here) >296: 0x00 >297: 0xab >298: 0xfd >At the start, the position in the file is at 286. >The original source uses this statement: > fscanf( fpData, "%d %d\n", &num0, &num1 ); >which leaves the file position at 296. This appears to be >incorrect. It correctly returns 2 as the number of items >read. Surely you meant 294. Reading another character as you describe below should not move you backwards in the file. Quote: >We can use the following statement: > fscanf( fpData, "%d %d%c", &num0, &num1, &ch ); >which leaves the position at 295, as we expect. >Is the behaviour of the first statement a defect? If so, >is there a source of information or a fix available? I don't think so. The first %d stops at the first character that cannot be part of the integer. This would be the blank at 291. The second %d skips over white space, process the digits, and stops at the next character that cannot be part of the integer. This is the LF at 294. If you add the %c, it will accept the LF and leave you at 295. If the file positions are fixed, you might be better off with fread and sscanf. You don't describe how it works in Unix but it should be the same. Quote: >Thanks, >Gordon Smith <<Remove the del for email>>
Wed, 23 Feb 2005 08:03:28 GMT

Page 1 of 1

[ 6 post ]