[musl] fcntl: Purpose of second DUPFD_CLOEXEC?

[Markus Wichmann <nullplan@gmx.net>]

Hi all,

I just stumbled upon the code to emulate F_DUPFD_CLOEXEC on old kernels.
At the moment, it looks like this:

|int ret = __syscall(SYS_fcntl, fd, F_DUPFD_CLOEXEC, arg);
|if (ret != -EINVAL) {
|	if (ret >= 0)
|		__syscall(SYS_fcntl, ret, F_SETFD, FD_CLOEXEC);
|	return __syscall_ret(ret);
|}
|ret = __syscall(SYS_fcntl, fd, F_DUPFD_CLOEXEC, 0);
|if (ret != -EINVAL) {
|	if (ret >= 0) __syscall(SYS_close, ret);
|	return __syscall_ret(-EINVAL);
|}
|ret = __syscall(SYS_fcntl, fd, F_DUPFD, arg);
|if (ret >= 0) __syscall(SYS_fcntl, ret, F_SETFD, FD_CLOEXEC);
|return __syscall_ret(ret);

And I'm wondering what the point of the second call to F_DUPFD_CLOEXEC
is. If it is just to test that the argument is valid, then why not just
get rid of the block? F_DUPFD has the same constraints on the argument.

Getting rid of that block also has the advantage of being able to factor
out the F_SETFD call. Then it would simply be

int ret = __syscall(SYS_fcntl, fd, F_DUPFD_CLOEXEC, arg);
if (ret == -EINVAL) ret = __syscall(SYS_fcntl, fd, F_DUPFD, arg);
if (ret >= 0) __syscall(SYS_fcntl, fd, F_SETFL, FD_CLOEXEC);
return __syscall_ret(ret);

Much nicer, isn't it? And it doesn't even allocate a file descriptor
uselessly.

Ciao,
Markus