This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
Re: Cleaning up for NULL handles
At 09:58 PM 9/21/2002 -0400, Christopher Faylor wrote:
>So, although the fact that CreateFile will return INVALID_HANDLE_VALUE
>on error is documented, I think we can safely assume that CreateFile
>will never return a NULL handle either.
Fair enough. I would still recommend to apply the patch because it
guarantees that invalid io_handles have the same value (0 or -1, depending
on handlers) in a parent and a dup'ed child, avoiding a source of bugs.
It doesn't add any new lines, only deleting two useless ones.
The matter of locks with negative lengths was left unresolved, around
line 475 in fhandler_disk_file.cc
According to
http://www.opengroup.org/onlinepubs/007908799/xsh/fcntl.html
"If l_len is positive, the area affected starts at l_start and ends at
l_start + l_len-1. If l_len is negative, the area affected starts at
l_start + l_len and ends at l_start-1. Locks may start and extend beyond
the current end of a file, but must not be negative relative to the
beginning of the file. A lock will be set to extend to the largest
possible value of the file offset for that file by setting l_len to 0."
So there should be a += in the third line below.
if (fl->l_len < 0)
{
win32_start -= fl->l_len;
win32_len = -fl->l_len;
}
In addition the sentence about not being negative relative to the beginning
of a file implies (please verify this) that the condition win32_start < 0
below should always result in EINVAL. There is no need to subtract the negative
of a negative number to try to fix things up :)
if (win32_start < 0)
{
/* watch the signs! */
win32_len -= -win32_start;
if (win32_len <= 0)
{
/* Failure ! */
set_errno (EINVAL);
return -1;
}
win32_start = 0;
}
If you agree I will send a patch. You may also decide that it's faster
overall for you to edit the file directly.
Pierre