🚀 go-pugleaf

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

> It is my understanding that ReadFile() is the
> same as the ANSI C fread() function.

Only in concept.  Their internal implementations are different, though,
having come from different APIs.

> Therefore, ReadFile() does a straight binary read
> from the file into the memory buffer, given whatever
> size of bytes is asked for.  So, ReadFile() has no
> way to tell if it has read a null character, which may
> or may not be in the byte stream it reads.

Correct.  ReadFile() does not actually look at the data being copied into
your buffer.  If anything, the only processing it does do is to make sure
the requested number of bytes is actually available for reading, and sets
the lpNumberOfBytesRead and return values accordingly.  But that's it.

> But, after I took out the statements to append the null
> character to the buffer in the Petzold code, I tested it
> by reading several different text files to see if would
> crash and it didn't. I fully expected it to crash on at
> least one of the files I read, so that is why I started
> questioning what exactly was going on.

The fact that you did not experience a crash suggests one of two
possibilities:

1) There was a null present somewhere.  Remember my earlier statement about
SetWindowText() scanning through memory.  If there is no null in your actual
buffer, then SetWindowText() will go outside the bounds of your buffer and
into the surrounding memory.  If the process happens to have the appropriate
access rights to that other memory, then SetWindowText() remains happy to
continue on.  It has no concept of buffer boundaries (in fact, that is more
of a human-defined concept than a machine one).  As long as there happens to
be a null somewhere in that surrounding memory, then SetWindowText() will
eventually encounter it.  The only side effect, depending on what the actual
memory contents are and how SetWindowsText() handles non-printable
characters, is that you may or may not see some gibberish at the end of your
displayed text, that's all.  Chances are, there will be a null encountered
close by to the buffer, especially if the surrounding memory contains
non-textual binary data (nulls are common in binary values).

2) The destination window's handler for the WM_SETTEXT message (which is all
SetWindowText() does - sends that mesage to the window passing it the same
data pointer) is doing error handling internally so that it can return back
to the calling code gracefully even if an error occurs.  This is
particularly important for APIs to do, especially those implemented in DLLs
as the Windows API is.  Exceptions/crashes are not supposed to be allowed to
cross the API/DLL boundary, unless you *really really really* know what
you're doing on the lower machine levels.

> Now the question I have is when a string is written to
> a file, does the null character also get written to the file.

That is entirely dependant on the program that wrote the file in the first
place.  File data is program-specific.  If the program writing the file
wants to write a null into it, it will do so, otherwise it won't.  Just like
ReadFile() makes no assumptions on the actual contents of the data, neither
does WriteFile().


Gambit