From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 6262022AB5 for ; Thu, 22 Aug 2024 15:53:14 +0200 (CEST) Received: (qmail 17879 invoked by uid 550); 22 Aug 2024 13:53:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 17840 invoked from network); 22 Aug 2024 13:53:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1724334780; x=1724939580; i=nullplan@gmx.net; bh=9ZjhDFSeZwQl67JPKoMm8+QFdAaOF8CGn9ygQdP3hPM=; h=X-UI-Sender-Class:Date:From:To:Subject:Message-ID:MIME-Version: Content-Type:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=B9xEJ6PTvwpOG/gkxxd7Uc/3cn1tsbySmLZ0SJ0kueQ2MxDUO74DqI09DJ5tRevW BJ/Ppp2YHacHME+VCt7ldH6pJxOtcueLarLkarBd50UzcHf272UcQv+MvS39aMm51 xx6GBPU0VyD76YHCUfRxV9+FqXzluAcxVl10UJ2p38pB3eJlNzISaOBi5IR4gVpRh uJH+xjQY/g5gmNajXeWhJ+1SeKWxzCKBBx3NYk34FkV9rXuqijZhTZ1ub2qpwmYfA 70yzla5+SH57CatZ4qOCVglOPsdtx5aBSLqT3omIvUY1G14exgVRyboGCmIk/Zn72 OxQ0j3Ej8kzVBA+cIQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 22 Aug 2024 15:52:58 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Provags-ID: V03:K1:pLuuaOu2uNaCitlVoOEmH7e4ZK9kD1L+5h0HdftoRATojTquBc2 T5eXPLZYyIDf1vho5mVPRr0uPsGYQXUQP5w3LLzJ9ozgYEEf+iqFAPttWkE2VCSpeEPn5H9 OwGWQBOPtMoRNOmos6uU2qOt6MXhgQXHNkxY7PvUcdhDsElzfPQFjgVTjHrKQedwRiwNbS9 Wzg3WlmpPyMldm55i5GCg== UI-OutboundReport: notjunk:1;M01:P0:lC5/TUaiZc8=;UnHATXlLxS7WoDDnOjc8AISz+DW 2iI31DxdVo5+BipKSp1QmhhtiNmm07GSvDq4+nlA9ys2CkrK7K9ltpxQrKqe4IxN437o3CWo/ hA51uJgpLNl9aroG/Ve8Jbj+yGYsbS61ywkODZPUkCy/uUC2Oc1WZhP/KZoXxWCTLc5WLUXQ/ wwCLiYHQ1MQ41nukAP0rfSFL7ufcGNVBiq7vCbAK/JkB1vJtJtyoEsrT0+boVzGjHtcXGF/M5 7tHCSC0vStWhx7v8loMhgZzKXLNj3NRIc5sRTxPE9RPgOPHTQJWWKnMSOEnoJSqoQm6WL5Lya j4u048qaSbMfkfMQcTvz4qD0HhfKB4TQuEEg6KHa0HBxGrh3E6j7rkf5LWf+unHykKzsw3k+O ptF0gp72YF31cdBKY+ZKwTnhbla+a7J7zDPvZsa5ucGEnv+Av0chzzirjolVaW6pu8lBLsoFu NQyYyMmwdxDC0zfhTEjqnBL5ZH2OJ3KkX6c6FD4CP6Kah3gl/N/8CP4CRouidg2RbJYUgk3bp S7qvn6n2vzKOzFkwpZAU6xhRE3sAOFHvuNNHYgaAB9eww0aRfooAK0PB8dB/p+p4TWsApZKh1 wwIV9+c6hNteABTfjJtTNtf3hIUf2HUM5YxBtWvoA/Es+7q6lgekCKgCn1jGYYDL6Yu07+wQL anaqheSvtg8JxSjSVqNyav/wxPTAkgcZ6dYZRZacS1bZF5guVY8kCH378jgAknLkvCNv6wsA+ 52+RAdVcqU4rRRHugatWkZGbXzDMx4tUHKTJLmKRmIaCRhbW3kyXMReRfta2b/EteVnaFYnAR MVsJIKvWOk+5fLC5ZZblW8uQ== Subject: [musl] fcntl: Purpose of second DUPFD_CLOEXEC? 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