🚀 go-pugleaf

"Bill Carson" <bcarson892003atyahoodotcom> wrote in message
news:3ec53c62@newsgroups.borland.com...

> During this process I have seen that Petzold
> appends null characters to the buffer that receives
> data before sending the text to an edit control
> (in his Poppad3 example, Chapter 11).  But, I've
> noticed if I skip this step and compile Poppad3,
> the result is the same. The buffer is still
> used by SetWindowText to fill the edit control
> whether I append a null character or not.

It is always safer to allocate a little extra room in your buffers and
provide your own null characters.  If you don't do that, then you are
relying on the source data to already contain the nulls, and you're just
reading them into your buffer.  If the nulls are actually present in the
source data, then all is good, and putting your own nulls into the buffer as
well won't hurt anything.  But if the source data doesn't actually have the
nulls in it, adn you don't put in your own, then your buffer will not be
null-terminated correctly.  Depending on how you're processing the buffer,
that may or may not be a fatal issue.

In this particular case, it will be, because SetWindowText() expects a
null-terminated buffer.  If the null is not present in the buffer, then
SetWindowText() will just keep reading from memory until it finally
encounters a null, or until it crashes with an access violation.  Either
way, you'll be allowing SetWindowText() to potentially go outside the bounds
of your buffer, thus producing undefined results.

> I don't fully understand the buffer returned by
> ReadFile()

It just just a chunk of raw data from the file, provided as-is, unprocessed.

> I assume it is just a pointer to a block of memory I allocate

Correct.

> with the value I get from GetFileSize()

In general, you shouldn't be handling files that way.  For small files that
may be ok, but for large files you'll eat up more of your system's memory
the larger the file is.  When working with large files (or any files in
general), it is better to have a fixed-size buffer and then read the file in
pieces, looping through the file filling your buffer with another chunk of
data and then processing it each time, until you are finished reading what
you need to read.  If you need to deal with the file data as a whole, then
using a memory mapping via CreateFileMapping() and MapViewOfFile() would be
better, that way you can access the file data directly without loading the
whole thing into memory.

> Is it safe to assume that ReadFile() never returns a
> null character in the buffer after a read?

ReadFile() doesn't do anything with the data it reads.  It is a straight
copy-to-memory operation, copying from the file into your memory buffer.
Whether or not the file data being read contains its own nulls, that is a
completely different issue.

> Or, does it place one there after a read?

No.


Gambit