From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10609 invoked from network); 24 May 2022 13:33:09 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2022 13:33:09 -0000 Received: (qmail 24315 invoked by uid 550); 24 May 2022 13:31:20 -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 24244 invoked from network); 24 May 2022 13:31:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653399079; x=1684935079; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=8lyXp7b+y/coVsiKN+2O/CueSXcGLA/b0AqDpHwwp+g=; b=RoNm4K+pUlUJVtyWUrO4hHvBrlis+lVcA+HncryyTr2ThnlhbF5fPL4m vKAUU47JYqYh0plgfgQZcnk8iaMu5BCsSSuZ/UHAr2J4NAz0p9P8qyxIy 9OkS2GdwQmGmLyk7/OAXHOT5rzCYAr8JHeDKyNrhSBQxswIeklYkxh/Gb xCPLl4iO1tpLcIONQ6Fk0B4zuiJiTws8x4xCH1dNKfFSRp9i0O7HtBFQq rNHuUk1p8POTwm3JUbpHxPNwhSuML4M3yooQyMHX/gzC/7pu59xkAFwl4 07QCGFeXPJpJZqVnOMFfY1iOXKX72wzI6qZGELB/I/5yE9ip2XtEi3WcN A==; X-IronPort-AV: E=McAfee;i="6400,9594,10356"; a="298849550" X-IronPort-AV: E=Sophos;i="5.91,248,1647327600"; d="scan'208";a="298849550" X-IronPort-AV: E=Sophos;i="5.91,248,1647327600"; d="scan'208";a="548475010" Message-ID: Date: Tue, 24 May 2022 21:31:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Rich Felker Cc: musl@lists.openwall.com References: <20220524080704.70894-1-jiaqing.zhao@linux.intel.com> <20220524122741.GT7074@brightrain.aerifal.cx> From: Jiaqing Zhao In-Reply-To: <20220524122741.GT7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] [PATCH] dirent: implement getdents64 On 2022-05-24 20:27, Rich Felker wrote: > On Tue, May 24, 2022 at 04:07:04PM +0800, Jiaqing Zhao wrote: >> In musl, getdents64 is an alias of getdents, but the type annotation >> of these two functions are different according to man page[1], causing >> compile errors. This patch implements the standard getdents64. >> ssize_t getdents64(int fd, void *dirp, size_t count); >> >> [1] https://man7.org/linux/man-pages/man2/getdents.2.html >> >> Signed-off-by: Jiaqing Zhao >> --- >> include/dirent.h | 3 ++- >> src/linux/getdents.c | 6 +++++- >> 2 files changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/include/dirent.h b/include/dirent.h >> index 650ecf64..4c5367c2 100644 >> --- a/include/dirent.h >> +++ b/include/dirent.h >> @@ -11,6 +11,7 @@ extern "C" { >> #define __NEED_off_t >> #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) >> #define __NEED_size_t >> +#define __NEED_ssize_t >> #endif >> >> #include >> @@ -50,6 +51,7 @@ long telldir(DIR *); >> #define IFTODT(x) ((x)>>12 & 017) >> #define DTTOIF(x) ((x)<<12) >> int getdents(int, struct dirent *, size_t); >> +ssize_t getdents64(int, void *, size_t); >> #endif >> >> #ifdef _GNU_SOURCE >> @@ -65,7 +67,6 @@ int versionsort(const struct dirent **, const struct dirent **); >> #define versionsort64 versionsort >> #define off64_t off_t >> #define ino64_t ino_t >> -#define getdents64 getdents >> #endif >> >> #ifdef __cplusplus >> diff --git a/src/linux/getdents.c b/src/linux/getdents.c >> index 796c1e5c..923a8076 100644 >> --- a/src/linux/getdents.c >> +++ b/src/linux/getdents.c >> @@ -9,4 +9,8 @@ int getdents(int fd, struct dirent *buf, size_t len) >> return syscall(SYS_getdents, fd, buf, len); >> } >> >> -weak_alias(getdents, getdents64); >> +ssize_t getdents64(int fd, void *buf, size_t len) >> +{ >> + if (len>INT_MAX) len = INT_MAX; >> + return syscall(SYS_getdents64, fd, buf, len); >> +} >> -- >> 2.34.1 > > The inclusion of LFS64 API stuff in musl was a historical mistake that > resulted from attempting glibc ABI-compat, not a set of interfaces we > want. What happened was that the weak aliases for glibc ABI compat > were included, then broken configure scripts that checked only for > symbol linkage but not for a working declaration "detected" these > functions as usable, producing miscompiled code from lack of > declartion. Since it was intended that musl-built programs never > reference these ABI-compat-only symbols, it was "fixed" by adding the > macros to redirect them to the correct functions, but this caused lots > of problems and we're still trying to extricate the mess. If at some > point the glibc ABI-compat stuff can be moved entirely to the external > gcompat project, the macros will be removed entirely. > > As such, I think this patch is not appropriate for inclusion. > > Rich Got your point. In other ABI-compat-symbols, the redirection works as the function signature are the same, but getdents64 and getdents are not. A type cast is needed to make them compatible. Modifying the macro can help solve this difference, will this be an appropriate solution? #define getdents64(fd, buf, len) getdents((fd), (struct dirent *)(buf), (len)) Jiaqing