return value for _lread
Hi,
I'd like to know what is the expected behavior for the _lread functions (kerlnel.dll # 82 and kernel32.dll # 596) when uBytes == 0. This is not described in the API spec.
I.e., if we ask to read 0 bytes, what will happen:
an error? which one?
what is returned by the function? 0? -1?
does that depend on wether the EOF has been reached?
does that depend on the windows' version?
Thanks.
I'd like to know what is the expected behavior for the _lread functions (kerlnel.dll # 82 and kernel32.dll # 596) when uBytes == 0. This is not described in the API spec.
I.e., if we ask to read 0 bytes, what will happen:
an error? which one?
what is returned by the function? 0? -1?
does that depend on wether the EOF has been reached?
does that depend on the windows' version?
Thanks.
Is this valid if the file reader has just reached the EOF?
For example, imagine that EOF has already been reached, and one asks for a _lread of 0 bytes.
In the specs, it is said:
"If the number of bytes read is less than uBytes, the function has reached the end of file (EOF) before reading the specified number of bytes. "
So, would it return 0 even though EOF was reached?
Thanks
For example, imagine that EOF has already been reached, and one asks for a _lread of 0 bytes.
In the specs, it is said:
"If the number of bytes read is less than uBytes, the function has reached the end of file (EOF) before reading the specified number of bytes. "
So, would it return 0 even though EOF was reached?
Thanks
assuming no error, _lread() returns the number of bytes that were read. This is the lesser of the number requested or the number remaining after the current file position. If you specify 0 bytes to be read, then the procedure will read 0 bytes (regardless of the current file position) and will return 0. Thus when you read 0 bytes it doesn't matter what the current file position is.
both documentation and use---but not of _lread(). 'm assuming (and it is a safe assumption) that it works like the 100s of other functions that perform the same task (C and C++ have several that work like this, DOS has a read service that works like this, Win32 has the ReadFile() function.) Thus there is a sort-of convention to how a read() function is supposed to work and _read() will almost certainly follow it. If it didn't it would have to have a good reason and would have to make it clear in the documentation because programmers will assume it does.
Thanks for using Experts Exchange.
Please provide your email to receive a sample view!
*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.