NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/mac/programm/22014

Text File | 1993-01-23 | 1.6 KB | 33 lines

Newsgroups: comp.sys.mac.programmer
Path: sparky!uunet!charon.amdahl.com!netcomsv!netcom.com!cokenias
From: [e-mail] (Damon Cokenias)
Subject: Re: Recommended way to deal with large memory buffers?
Message-ID: <[e-mail]>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <[e-mail]> <[e-mail]>
Date: Sat, 23 Jan 1993 08:50:39 GMT
Lines: 22

In article <[e-mail]> [e-mail] (James Gustave) writes:
>
>  I'm working on an encryption application, and I need to go through a file,
>encrypt it, and write it to a new file.  The encryption routine takes a Ptr
>to a buffer, and a count of the number of bytes to process.  For small files,
>it makes sense to read the whole file into the buffer and do the encryption.
>However, this means that the maximum size of the file to be encrypted is
>determined by the amount of memory the program can allocate.  On the other
>hand, if I did the encryption incrementally, writing the parts to a temp file,
>then there might be a lot of unnecessary disk access which would slow down
>the process.

Well, you could read in your maximum amount to encrypt, pass it to your
encryption routine.  Then, reposition the file mark and write the information
to the beginning of the file.  Obviously, this could be a pain if you're also
doing compression.  Then, the file mark will be advanced to the place you
left it after the initial read and then you can continue to process the file.

This ha the advantage of not using any excess disk space.

-Damon Cokenias