Re: WriteFile()
- From: "Hector Santos" <nospamhere@xxxxxxxxxxxxxx>
- Date: Mon, 11 Apr 2005 06:22:53 -0400
"Chris Burnette" <burnette@xxxxxxxxxxxxxxxxxx> wrote in message
> ...
> I didn't have anything to do with the design and implementation of
> WriteFile... I'm only writing based on my experience, so take my advice
for
> what it's worth. One basic tenet of programming is to check return
values.
> These return values are in there for a reason, and they should be checked
> accordingly. Making assumptions about what the expected behavior is when
> that behavior is not clearly spelled out in the documentation isn't a good
> idea.
Chris,
I'm glad you not designing my products <g> MSDN serves as a reference. It
does not replace the 28+ years of a rich software engineering background
especially in the Telecommunications market (note that is before Windows!)
I think you have some misunderstanding on decades old fundamental FILE I/O
and communications principles and I think you might have read the docs
incorrectly on this. The ReadFile() analogy was poor and finally, if these
unexpected possibilities did exist, then thouands of applications based on
standard RTL streaming and low-level file handling functions would
fundamentally break down. They are inherently synchronous and their
implementation is based on fundamental blocking I/O operations.
For a non-timeout prepared sync device, whether its read or write, the
request is BLOCKED until the I/O is completed. For a READ, there is only
one condition for a partial read - not enough bytes available (EOF). This
is not the same thing as Writing where writing X is based on having the
EXPECTED space available to write.
Again, when a timeout concept is NOT part of the design, a BLOCK call can
only behave one way - BLOCKED until it completes the request. This is the
essense of asynchronous vs sychronous I/O operations. There is no bending
of the rules. Its one way only. Anything else that happens is a FLAW or and
ERROR.
Therefore, when there is NO timeout conditions, a blocking WriteFile() call
only return with 1 of 2 possible design expectations:
- TRUE with request == written
- FALSE with and extended error code set.
If a TIMEOUT does occur here with a TRUE result and no error, then we have a
DESIGN FLAW in the sub-system. That function should NEVER return until it
finishes or an error occurs.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
"Chris Burnette" <burnette@xxxxxxxxxxxxxxxxxx> wrote in message
news:uD6BCqkPFHA.2468@xxxxxxxxxxxxxxxxxxxxxxx
> I think one of the problems that I see is that there isn't enough
> documentation on the expected behavior of Read/WriteFile. There is no
> mention of what success really means under various conditions. It's up to
us
> to try to figure it out. And then there's always unexpected behaviors due
to
> hardware malfunctions, etc. Part of this is probably because
Read/WriteFile
> can be used in so many different ways, fron files, serial ports, pipes,
etc.
> Heck, the documentation doesn't even mention the various errors that
> GetLastError can return. Try looking in the documentation for WriteFile to
> see what the return value for GetLastError is when a disk is full. Not
even
> mentioned.
>
> But, let's apply your argument to ReadFile. Let's assume we're using
> ReadFile to read a series of bytes synchronously. According to your
> argument, if ReadFile cannot read the requested number of bytes, it should
> fail. However, this isn't the case. The documentation for ReadFile states
> that when you read to the end of a file, it's normal for ReadFile to
return
> success with *lpNumRead < nNumToRead. When the end of file is read,
> *lpNumRead = 0 and ReadFile returns TRUE.
>
> Here's code taken from MSDN's documentation of ReadFile that demonstrates
> how to test for end of file condition:
> // Attempt a synchronous read operation.
> bResult = ReadFile(hFile, &inBuffer, nBytesToRead, &nBytesRead, NULL) ;
> // Check for end of file.
> if (bResult && nBytesRead == 0 )
> {
> // we're at the end of the file
> } So, ReadFile doesn't apply the logic of stating that it's a failure
> condition when *lpNumRead < nNumToRead in sync situations. It also uses
the
> same timeout methodology that WriteFile exhibits when using serial port
IO.
>
> The point I was trying to make is that it's probably not a good idea to
> assume that *lpNumWritten == nNumToWrite when WriteFile returns TRUE in
sync
> mode (which was the original question). The fact that the documentation
> states that this assumption is false to begin with only reinforces my
> argument. Should it be the other way around? A good argument could be made
> for that, I agree. But nowhere in the documentation does it state this (in
> fact, it states that WriteFile can return TRUE when *lpNumWritten <
> nNumToWrite under certain circumstances).
>
> I didn't have anything to do with the design and implementation of
> WriteFile... I'm only writing based on my experience, so take my advice
for
> what it's worth. One basic tenet of programming is to check return
values.
> These return values are in there for a reason, and they should be checked
> accordingly. Making assumptions about what the expected behavior is when
> that behavior is not clearly spelled out in the documentation isn't a good
> idea.
>
> Chris Burnette
> EOIR Technologies
>
>
> "Hector Santos" <nospamhere@xxxxxxxxxxxxxx> wrote in message
> news:%23R7RzcaPFHA.1172@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > "Chris Burnette" <burnette@xxxxxxxxxxxxxxxxxx> wrote in message
> > news:##RKupYPFHA.204@xxxxxxxxxxxxxxxxxxxxxxx
> >
> >> Typically, I've found that WriteFile will report that it's written the
> > same
> >> number of bytes that you've told it to write. I would think that an
> >> application should not necessarily assume that this is the case; these
> >> return values are in there for a reason.
> >
> > Chris, I respectfully disagree.
> >
> > This is not a fuzzy situation. There is no unknown carbon intelligence
> > making decisions for us here. It is black and white. There is no gray
> > area.
> >
> > If the design calls for a sync behavior with no regards to timeouts,
then
> > your must design the code based on expected behaviors. A sync call to
> > WriteFile() must return the write amount equal to the request amount.
> > Otherwise there is an error condition.
> >
> > If you can't "trust" the result, then there MUST be a reason for the
lack
> > of
> > trust. You can't program this stuff blindly... but then again, thats
> > probably why bugs exist :-)
> >
> > Here is another way to look at this:
> >
> > If you design your I/O with async in mind, then you using IO PENDING
logic
> > to properly synchronize it.
> >
> > If you design your I/O with sync, if what you say is true, then YOU have
> > no
> > choice but to have every WriteFile() call in your code changed to use
loop
> > concept watching for no error partial writes.
> >
> > Unless you specially expect this type of behavior (using serial write
> > timesout for example), then that is completely redundant.
> >
> > I'm not saying that isn't ok (every sync writefile replaced with a
wrapper
> > that watches for generic timeout partial writes), but you might as well
> > use
> > a ASYNC I/O communications design.
> >
> > But if I have an sync WriteFile() with no timeout parameters set for the
> > device (if possible), then I expect a block call and a 100% complete
> > write.
> >
> > --
> > Hector Santos, Santronics Software, Inc.
> > http://www.santronics.com
> >
> >
> >
> >
>
>
.
- Follow-Ups:
- Re: WriteFile()
- From: Alexander Grigoriev
- Re: WriteFile()
- From: Chris Burnette
- Re: WriteFile()
- References:
- WriteFile()
- From: Frank A. Uepping
- Re: WriteFile()
- From: Hector Santos
- Re: WriteFile()
- From: Gary Chanson
- Re: WriteFile()
- From: Chris Burnette
- Re: WriteFile()
- From: Hector Santos
- Re: WriteFile()
- From: Chris Burnette
- WriteFile()
- Prev by Date: Re: Threading Delay
- Next by Date: Re: Get number of child threads
- Previous by thread: Re: WriteFile()
- Next by thread: Re: WriteFile()
- Index(es):
Relevant Pages
|
Loading
