Hi Collin,
> The bug report got addressed today.
Nice! That was quick (probably because it was a kernel issue — on libc issues
they are much slower).
> I think we may have the ordering wrong
> in lib/dup3.c:
>
> if (newfd < 0 || newfd >= getdtablesize () || fcntl (oldfd, F_GETFD) == -1)
>
Hi Bruno,
On 5/18/24 5:03 PM, Bruno Haible wrote:
> And it's a good idea to reference the bug report in a comment:
> @c https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=58266
> So that in the future it helps us to understand what the bug is
> about and how to reproduce it in newer versio
Hi Collin,
> I've pushed the patch with a ChangeLog + the second of your
> suggestions.
Good!
> I've submitted a bug report with the links to documentation and a test
> program for them [1]. I think I even found the right place to change
> the behavior, so hopefully someone takes a look at it so
Hi Bruno,
On 5/18/24 4:54 AM, Bruno Haible wrote:
>> +/* On NetBSD dup3 is a no-op when oldfd == newfd, but we expect
>> + an error with errno == EINVAL. */
>
> (What is "we", and who expects something from whom?)
> I would find it less confusing if written like this:
>
Hi Collin,
> How does this look? Passes tests on NetBSD 10.00.
The position in the code is right.
Only the comment is confusing me:
> +/* On NetBSD dup3 is a no-op when oldfd == newfd, but we expect
> + an error with errno == EINVAL. */
(What is "we", and who expects
Hi Bruno,
On 5/18/24 3:42 AM, Bruno Haible wrote:
> An interesting approach. But I think this added code comes too early:
> In case of oldfd == newfd && newfd < 0, it would fail with EINVAL instead
> of EBADF.
>
> How about trying the system call first, and test for newfd == oldfd only if
> that
Hi Collin,
> Currently dup3 is replaced unconditionally. I made this change in a
> NetBSD virtual machine and the test program passes:
>
> $ git diff .
> diff --git a/lib/dup3.c b/lib/dup3.c
> index a810d3be19..7674f042a4 100644
> --- a/lib/dup3.c
> +++ b/lib/dup3.c
> @@ -34,6 +34,15 @@ dup3 (int
