🚀 go-pugleaf

nett@technix.mn.org (Jerry Nettleton) writes:
: A program I'm working reads a text file to load a database.  When an
: error is encountered in the text, I need to go backwards in the file
: to a saved location and print the text and error messages.  I've tried
: to use 'ftell/fseek' and 'fgetpos/fsetpos', but these functions don't
: work reliably when buffered I/O is enabled.  They return multiples of
: 0x0200 (BUFSIZ).  I've also tried to open the twice, one file pointer
: to read lines and parse the info and the other one for generating
: error messages.  Unbuffered I/O slows down the conversion process
: significantly...
: 
: Any ideas?

You might want to consider using the low level I/O functions:
open()  - opens the file
sopen() - open for file-sharing
creat() - make a new file or truncate an existing one
dup() & dup2()  - force a second file handle to refer to an open file
lseek() - set current position within the file
tell()  - get current position within the file
read()  - read bytes from file (up to 65534 at a time)
write() - write bytes to file   "      "     "     "
eof()   - determines if EOF has been reached
close() - closes the file

They are slightly more of a pain to use, but can be much faster if you
read/write in large chunks.  My book (The MSC Bible 2nd edition) says
that although none of these functions are ANSI compliant, almost all of them
can be used with every compiler.  The exception being that some are not
Unix and/or Xenix compatible.  You didn't mention what compiler you are
using.  I would venture to say that you should be able to do exactly what
you want to do using these functions.  If you set up a large array (20k or
so) for moving big chunks with read() and write(), you should get blazing
speed compared to the high level functions.  If you are not moving too many
bytes in or out and are mostly seeking and reading small pieces, things
should still clip right along.

Hope this is helpful, and please let me know what happens.

--
cwilkins@irscscm.uucp                                   /======================\
uunet!mimsy!prometheus!media!ka3ovk!irscscm!cwilkins    | Micro-Sig(tm) pellet |
N3HAZ@KA3RFE.MD.USA.NA                                  |   -just add water    |
...or you can call me Charlie                           \======================/

In article <1992Aug6.154146.11988@irscscm.UUCP> cwilkins@irscscm.UUCP (Charlie Wilkinson) writes:
[Lots deleted]
>You might want to consider using the low level I/O functions:
>open()		>sopen()	>creat()	>dup() & dup2()	>lseek()
>tell()		>read()		>write()	>eof()		>close()
>
>My book (The MSC Bible 2nd edition) says
>that although none of these functions are ANSI compliant, almost all of them
>can be used with every compiler.  The exception being that some are not
>Unix and/or Xenix compatible.

I thought these WERE the unix file utilities.  (as opposed to the ansi
file utilities)  According the Borland C++ 3.1 online help, only eof()
is not ANSI compliant.  eof() can be avoided with lseek() and tell().

IMHO the Unix file utilities are easier to use than the corresponding
ANSI ones.

Since the DOS system level file utilities are so similar to the Unix
system level file utilities, it seems like the Unix style file access
should be the most effecient way to access files from DOS.

					--Phil

phil@cs.utexas.edu (Philip Smolen) writes:
>I thought these WERE the unix file utilities.  (as opposed to the ansi
>file utilities)  According the Borland C++ 3.1 online help, only eof()
>is not ANSI compliant.  eof() can be avoided with lseek() and tell().

Most of them are (sopen and eof are not, I think).  None of them are
specified by ANSI.

>IMHO the Unix file utilities are easier to use than the corresponding
>ANSI ones.

Possibly.  Unless you want formatted output, buffering, etc.

--
Lars.Wirzenius@helsinki.fi

In article <l85skiINN9vb@levelland.cs.utexas.edu> phil@cs.utexas.edu (Philip Smolen) writes:
>In article <1992Aug6.154146.11988@irscscm.UUCP> cwilkins@irscscm.UUCP (Charlie Wilkinson) writes:
>[Lots deleted]
>>You might want to consider using the low level I/O functions:
>>open()		>sopen()	>creat()	>dup() & dup2()	>lseek()
>>tell()		>read()		>write()	>eof()		>close()
>>
>>My book (The MSC Bible 2nd edition) says
>>that although none of these functions are ANSI compliant, almost all of them
>>can be used with every compiler.  The exception being that some are not
>>Unix and/or Xenix compatible.
>
>I thought these WERE the unix file utilities.  (as opposed to the ansi
>file utilities)  According the Borland C++ 3.1 online help, only eof()
>is not ANSI compliant.  eof() can be avoided with lseek() and tell().
>
>IMHO the Unix file utilities are easier to use than the corresponding
>ANSI ones.
>

For SOME applications, the UNIX I/O calls will be both faster and
easier to use than the ANSI calls that are built on top of them.
However, a program that uses these calls may not port to a non-Unix
system.  For operating systems with files systems are not organized
like they are in Unix, it it likely that these functions will not be
implemented.  Instead there will be functions like Q$DIO, _callio()
etc which give you the same low level access to the way that file
system is organized as creat() and friends give you on Unix.

Looking for "creat()" on other systems is about as sensible as looking
for Q$DIO on Unix.