1. where() behavior in append mode
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
2. Re: where() behavior in append mode
Bob writes:
> after 3 days of weeping and gnashing of teeth trying to
> squash a bug, I noticed a problem with where()
I ran your demo program and got the same incorrect results.
I also translated/compiled with DJGPP and got the correct results.
I believe you are correct that where() is unreliable
on files opened in append mode when WATCOM is involved,
i.e. in ex and exw, which are compiled with WATCOM.
By the way, your example does work correctly if you call
flush() after puts(), but you shouldn't have to do that.
I searched the Web and found a message posted by someone
who encountered this same problem in Watcom 10.6 (that I'm using).
He also looked at the source code for Watcom 11.0, and
found that they have "fixed" the problem, by forcing a flush()
inside the C ftell() library routine that I call to implement where().
I think I'll just put a warning in the docs for where()
in the 2.3 final release. Not many people use where() with
files opened in append mode. You are the first to report this.
Thanks for the detailed error report, and I'm sorry about the
time and emotional energy you wasted.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: where() behavior in append mode
Hi Rob, Hi Bob 
Rob writes:
>Bob writes:
> > after 3 days of weeping and gnashing of teeth trying to
> > squash a bug, I noticed a problem with where()
> I ran your demo program and got the same incorrect results.
> I also translated/compiled with DJGPP and got the correct results.
> I believe you are correct that where() is unreliable
> on files opened in append mode when WATCOM is involved,
> i.e. in ex and exw, which are compiled with WATCOM.
> By the way, your example does work correctly if you call
> flush() after puts(), but you shouldn't have to do that.
> I searched the Web and found a message posted by someone
> who encountered this same problem in Watcom 10.6 (that I'm using).
> He also looked at the source code for Watcom 11.0, and
> found that they have "fixed" the problem, by forcing a flush()
> inside the C ftell() library routine that I call to implement
> where().
>
> I think I'll just put a warning in the docs for where()
> in the 2.3 final release. Not many people use where() with
> files opened in append mode. You are the first to report this.
> Thanks for the detailed error report, and I'm sorry about the
> time and emotional energy you wasted.
Maybe the better way may be a *new* document in docs
with such the local and temporary issues related just
to different C compilers and their versions and the
tips to work around that treacherous numerous
all standard but so different ANSI Cs.
Then you can strongly separate the inner Euphoria's
not so bad bugs :) from the old, nasty, secret C bugs :-[
and keep the pure EU docs more and more stable to make
the ISO standard EU in future.
Why not ISO EU standard, folks, peoples and nations ?
Why ?
Can we dream or no, we can not ?
Regards,
Igor Kachan
kinz at peterlink.ru
P.S. And I'm too lazy to corrupt
good library.doc and lib_u_z.htm
now and to correct them after
Watcom Open Source 1.0 released.
