From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 05B0C3857C47 for ; Mon, 17 Aug 2020 15:38:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 05B0C3857C47 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-194-6ZYf0JQUNd2xaC06YdlU5g-1; Mon, 17 Aug 2020 11:38:48 -0400 X-MC-Unique: 6ZYf0JQUNd2xaC06YdlU5g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AA42E1007463; Mon, 17 Aug 2020 15:38:47 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-112-9.ams2.redhat.com [10.36.112.9]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7A3CA70C3D; Mon, 17 Aug 2020 15:38:47 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id F35B4A806A2; Mon, 17 Aug 2020 17:38:45 +0200 (CEST) Date: Mon, 17 Aug 2020 17:38:45 +0200 From: Corinna Vinschen To: Eshan Dhawan Cc: newlib@sourceware.org, joel@rtems.com Subject: Re: [PATCH] Added FTW.H Methods Message-ID: <20200817153845.GH3272@calimero.vinschen.de> Reply-To: newlib@sourceware.org Mail-Followup-To: Eshan Dhawan , newlib@sourceware.org, joel@rtems.com References: <20200817094238.GD3272@calimero.vinschen.de> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 15:38:52 -0000 On Aug 17 16:10, Eshan Dhawan via Newlib wrote: > > > On 17-Aug-2020, at 3:12 PM, Corinna Vinschen wrote: > > > > On Aug 13 08:11, Joel Sherrill wrote: > >>> On Thu, Aug 13, 2020 at 3:17 AM Corinna Vinschen via Newlib < > >>> newlib@sourceware.org> wrote: > >>> > >>> On Aug 13 03:08, Eshan dhawan via Newlib wrote: > >>>> Signed-off-by: Eshan dhawan > >>>> --- > >>>> newlib/configure.host | 2 +- > >>>> newlib/libc/include/ftw.h | 64 ++++++++++++++ > >>>> newlib/libc/posix/Makefile.am | 2 +- > >>>> newlib/libc/posix/ftw.c | 36 ++++++++ > >>>> newlib/libc/posix/nftw.c | 154 ++++++++++++++++++++++++++++++++++ > >>>> 5 files changed, 256 insertions(+), 2 deletions(-) > >>>> create mode 100644 newlib/libc/include/ftw.h > >>>> create mode 100644 newlib/libc/posix/ftw.c > >>>> create mode 100644 newlib/libc/posix/nftw.c > >>> > >>> Why do we need _FTW_ENABLE_? > >>> > >>> What do we need the foo64 variants for? WHile newlib defines > >>> _LARGEFILE64_SOURCE for __linux__ and __RDOS__, it's not used > >>> anywhere else in newlib itself. > >>> > >>> Also, there's a ftw/nftw implementation in Cygwin already. Did you > >>> check it for inclusion into newlib, or to drop the Cygwin version in > >>> favor of a new newlib versions? We could at least share a common > >>> header, but then we will have to use the flag values already used in > >>> the Cygwin implementation for backward compatibility. > >>> > >> > >> We went straight to *BSD for implementations and didn't look at Cygwin. > > > > Cygwin's ftw is OpenBSD. Which BSD is this ftw taken from? > It’s taken from MUSL Libc Ok. > >> I've asked Eshan to replace the implementation with the Cygwin one. > >> Hopefully that's easy and allows one more piece of shared software. > > > > It's not *that* easy because OpenBSD's/Cygwin's ftw(3) uses fts(3) under > > the hood. > That’s the same reason We couldn’t use FTW from BSD > > > > While sharing code is good, your implementation is more compact, which > > speaks for your code. > > > > However, I'd like to ask for ftw.h compatibility at least, so perhaps > > Cygwin can use this other ftw, too at one point. > > > > But even then, there's still the _FTW_ENABLE_ and _LARGEFILE64_SOURCE > > stuff I asked about. > _FTW_ENABLE_ was there because the FTW implementation required pthread_setcancelstate () That puzzles me a bit. Not setting _FTW_ENABLE_ disables ftw entirely, just because it requires pthread_setcancelstate. However, newlib already supports a flag _STDIO_WITH_THREAD_CANCELLATION_SUPPORT to call pthread_setcancelstate only on targets providing it, see, for instance, newlib/libc/stdio/freopen.c. ftw could simply do the same. Thanks, Corinna