EOF confusion.

[mark smit]

Hello All,

I am a little confused as to why the following code loops for what seems to be forever. The DO UNTIL loop should bail out once the end of the file has been reached but I'm guessing the GET$ function resets this. Can someone please shed some light on this.

#compile exe


function pbmain as long
    dim Opcode as word
    dim Length as word
    dim Buffer as string
    
    
    rem open/create data file
    open"records.dat" for binary as #1
    
    
    do until eof(1) 'detect end of file
    
        get #1,,Opcode 'read record opcode
        get #1,,Length 'read record length
        get$ #1,Length,Buffer 'read record data
        
    loop
    
    
    close #1
    
    
    msgbox"done."
end function

------------------
Cheers

[Eric Pearson]

From the Help File:

If filenum is a binary file, EOF returns TRUE only if the most recent file operation was a read operation and that operation couldn't read the requested number of bytes.

In other words, when used with FOR BINARY, EOF only returns TRUE after you have attempted to read the file, and failed.

With BINARY it's often easier to compare SEEK to LOF.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited March 13, 2001).]

[mark smit]

Hello Eric,

I understand that but looking at the example above, GET$ would be the last unseccessfull read and it should trigger the EOF. All file operations should trigger the EOF when they are unable to read the required amount of bytes. I mean, why would the first GET statment trigger and EOF and the others reset it?

This is whats happening right now:

GET #1,,Opcode "EOF = TRUE"
GET #1,,Length "EOF = TRUE"
GET$ #1,Length,Buffer "EOF = FALSE"

GET$ shouldn't reset the EOF because there just isn't any data left to read.



------------------
Cheers!

[Eric Pearson]

Except that if the GET #1,,Length fails then Length will contain zero, so when you tell GET$ to "get zero characters" it says "ok, I did that".

Basically, the most recent read operation did not fail.

You see, the file may be getting larger in real time. For example another program may be adding to it. So unless a read operation actually fails, PB "pleads ignorance" about the state of EOF. As it should.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited March 13, 2001).]

[mark smit]

Hello Again,


As it turns out the offending variable that causes this problem was Length. At the time GET$ is executed the variable Length is ZERO. If the length to be read by GET$ is zero there cannot be any change in EOF because no read operation actually occured. However, in such a case the EOF should not be reset as PB does now.


------------------
Cheers!

[mark smit]

Eric,

I see where you're comming from now. I didn't concider that the file size may change between reads. Thanks for pointing that out! I wish PowerBasic would outline these internals in the help file.

------------------
Cheers!

[Bern Ertl]

Mark,

The file cannot be changed by *other* programs between reads in
your example because the OPEN statement defaults to LOCK READ WRITE.
*Your* program may read & *write* to the file opened as BINARY,
so your program has the ability to change the file between reads if
you program it so.



------------------
Bernard Ertl

[Lance Edmonds]

Bern, lets not try to confuse the issue for the lurkers... the lock mode is technically unrelated to the lack of EOF() detection.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[mark smit]

Lance,

Shouldn't the logic flow of the GET($) statment be as follows.

GET$ #1,0,a$: len(a$) = 0: EOF = UNCHANGED 'No read is performed so the state of EOF is unknown.
GET$ #1,8,a$: len(a$) = 8: EOF = FALSE
GET$ #1,8,a$: len(a$) = 4: EOF = TRUE

Calling GET$ with a length of ZERO is the same as not calling it at all and there for the state of EOF should not change.


I would just like to point out that this is really just for fun. I dont want to start a "lets change PowerBasic" thread here. I know of MANY diffrent ways to get around this but I thought it would be nice to clear this issue up for others that might run into this.



------------------
Cheers!

[Lance Edmonds]

I see your point, but I would suspect that R&D would not change this behavior as it may break existing code that relied on this behavior. Personally, I believe the compiler is acting correctly.

Changing this behavior would likely introduce more chances of [different] programmer error because of the special case applied to [not] setting the EOF state when zero bytes are retrieved.

That said, how many programmers actually want to intentionally retrieve zero bytes from a file?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[mark smit]

Hey Lance!

I tend to agree with you about changing this behavior. If this "feature" was removed it might very well expose accidental use of the current behavior. Thanks for the input guys!

------------------
Cheers!

[Mel Bishop]

Mark:
I ran across this problem in my DOS PB. I solved it by using:

Open "somefile.txt" for binary as #1
do
if lof(1) - loc(1) = 0 then exit loop
...
...
loop
close #1


------------------

[Paul Dwyer]

Not sure if it's related but,

When I open a CSV text file for INPUT and the file is in use still be excel then eof is not returned but the lof is 0 (if you check)

if you don't check for lof(0) you end up on an infinite loop

------------------
Paul Dwyer
Network Engineer
Aussie in Tokyo

[Lance Edmonds]

In this circumstance, are you sure the OPEN statement actually worked? IOW, if the file is locked, the OPEN statement should probably have failed with an error 70 or maybe 75.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

Mark, I dont want to be rude, but your problem is that you use
wrong programming-technic to terminate the loop.
In Binary/Random mode EOF is signalled after you read past EOF
EOF is correctly reset on your last read, the same will a Seek do

  on error resume next 
  Open file$ for binary as #1
  Do
   get #1,,Opcode 
   If EOF(1) Then Exit Do
   get #1,,Length 
   If EOF(1)Then goto Premature_Exit
   get$ #1,Length,Buffer 'read record data
   If Err = 62 Then 
    gosub handle_incomplete_data
   Else
    gosub process_correct_data
   End if
  Loop while not Eof(1)

This approch have I used for the last 25 years in diffrent
dialects of Basic


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited March 15, 2001).]

[mark smit]

Fred,

While I do agree with you to a point, the real objective behind this was to bring out some of the hidden features and behaviors in PowerBasic's compilers. For instance, I have not seen any documentation about the GET$ stament and what happens when the length provided is ZERO. My intention was to expose this sort of thing so that wwe can all gain a better understanding of what the compiler does. I certainly don't think it's rude to give very helpfull advise as you have I simply ran into this little bump and what to make sure that others understand why it happens.

------------------
Cheers!