Re: Bug with where()?

new topic     » goto parent     » topic index » view thread      » older message » newer message

Juergen writes:

> After activating the command flush(f), the program works as expected,
> but I think it also should work correctly without flush(f).

Thanks for your example.
I duplicated your results.
I think this is an example of what I say in the docs
for seek():

"After seeking and reading (writing) a series of bytes,
you may need to call seek() explicitly before you switch
to writing (reading) bytes, even though the file position
should already be what you want."

Explicit seeking, or flushing corrects these problems.

Your example ran the same (undesired) way with the DJGPP-built
interpreter as well. This seems to be a basic problem with C I/O.
It's not really under my control, except that I could do a forced,
hidden flush(), in some cases, causing a possibly severe loss of
performance.

One minor thing. I recommend that you use "ub", rather than "u",
although it doesn't seem to matter in your example...

"This function [seek()] is normally used with files opened in
binary mode. In text mode, DOS [and Windows]
converts CR LF to LF on input, and LF to CR LF on output,
which can cause great confusion when you are trying to count bytes."

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu