Announcement

Collapse
No announcement yet.

EOF confusion.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • EOF confusion.

    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.
    Code:
    #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

  • #2
    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).]
    "Not my circus, not my monkeys."

    Comment


    • #3
      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:
      Code:
      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!

      Comment


      • #4
        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).]
        "Not my circus, not my monkeys."

        Comment


        • #5
          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!

          Comment


          • #6
            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!

            Comment


            • #7
              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
              Bernard Ertl
              InterPlan Systems

              Comment


              • #8
                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>
                Lance
                mailto:[email protected]

                Comment


                • #9
                  Lance,

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

                  Code:
                  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!

                  Comment


                  • #10
                    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>
                    Lance
                    mailto:[email protected]

                    Comment


                    • #11
                      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!

                      Comment


                      • #12
                        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


                        ------------------
                        There are no atheists in a fox hole or the morning of a math test.
                        If my flag offends you, I'll help you pack.

                        Comment


                        • #13
                          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

                          Comment


                          • #14
                            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>
                            Lance
                            mailto:[email protected]

                            Comment


                            • #15
                              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
                              Code:
                                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).]
                              Fred
                              mailto:[email protected][email protected]</A>
                              http://www.oxenby.se

                              Comment


                              • #16
                                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!

                                Comment

                                Working...
                                X