OpenEuphoria

where() behavior in append mode

• Posted by bobelia200 at NETZERO.NET Jan 19, 2002
• 401 views

Hi Rob and everyone,

         I don't know if this has ever come up before, but after 3 days of 
weeping and gnashing of teeth trying to squash a bug, I noticed a problem 
with where().  My application (a filter creating files for a dictionary 
browser) was opening one file which contains the words and another which 
contains offsets to the words in the first file.  Both files already 
existed and were being added to, hence the need for where() and append mode.

         The following program demonstrates the problem:

-- N.B. This creates a file called 'CHKAPEND.@$&' in the current directory.
include file.e
integer outfile, w  sequence fname

procedure do_where(integer bytes, integer should_be)
     integer wh
     printf(1, "...writing %d bytes to outfile: ", bytes)
     puts(outfile, repeat(0, bytes)) -- write 'bytes' bytes to file
     wh = where(outfile)             -- get updated file position
     printf(1,"where(outfile)=%2d, and should be %2d\n", {wh, should_be} )
end procedure

procedure open_and_write(sequence fname, sequence openmode)
     integer file_size
     printf(1,"opening outfile for mode \"%s\"   ",  {openmode} )
     outfile = open(fname, openmode)

     w = where(outfile)  file_size = w
     printf(1,"where(outfile)=%2d\n",  w )

     for i = 3 to 5 do
         file_size += i          -- this is what where() should report
         do_where(i, file_size)  -- write 'i' bytes to file and display results
     end for

     w = where(outfile)
     printf(1,"subsequent call with no write: where(outfile)=%d\n",  w )
     w = where(outfile)
     printf(1,"subsequent call with no write: where(outfile)=%d\n\n",  w )
end procedure

fname = "CHKAPEND.@$&"
printf(1, "output file is \"%s\"\n", {fname})

open_and_write(fname, "w")  close(outfile)
open_and_write(fname, "u")  close(outfile)
open_and_write(fname, "a")  close(outfile)
-- END OF PROGRAM

         I get the following output:

c:\download\fixdict>ex CHKAPEND.EX
output file is "CHKAPEND.@$&"
opening outfile for mode "w"   where(outfile)= 0
...writing 3 bytes to outfile: where(outfile)= 3, and should be  3
...writing 4 bytes to outfile: where(outfile)= 7, and should be  7
...writing 5 bytes to outfile: where(outfile)=12, and should be 12
subsequent call with no write: where(outfile)=12
subsequent call with no write: where(outfile)=12

opening outfile for mode "u"   where(outfile)= 0
...writing 3 bytes to outfile: where(outfile)= 3, and should be  3
...writing 4 bytes to outfile: where(outfile)= 7, and should be  7
...writing 5 bytes to outfile: where(outfile)=12, and should be 12
subsequent call with no write: where(outfile)=12
subsequent call with no write: where(outfile)=12

opening outfile for mode "a"   where(outfile)=12
...writing 3 bytes to outfile: where(outfile)=12, and should be 15
...writing 4 bytes to outfile: where(outfile)=15, and should be 19
...writing 5 bytes to outfile: where(outfile)=19, and should be 24
subsequent call with no write: where(outfile)=24
subsequent call with no write: where(outfile)=24

HOWEVER , I translated and compiled with DJGPP and the problem GOES AWAY!

         Can anyone reproduce this behavior?  It would appear that the 
interpreter (or Watcom) is keeping a copy of this value in a queue of some 
sort.   The  returned value after the first write is what the last one 
should be.  I am running WIN98 and my 30G drive is in compatibility mode 
because of EZ-DRIVE but I doubt that's it. I get the same results on FAT16, 
FAT32, in windows and in straight DOS 7, and with ex and exw.  I've also 
tried mode "ab"; makes no difference.  It does NOT happen with exu 2.2 on 
RED-HAT 7.0.

         The work-around is to open in update mode and seek to end of file.

         Sorry for the long post but I believe that new topics sometimes 
need some more background, thus avoiding some obvious questions.

                                 Bob