From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D87B91F463 for ; Fri, 3 Jan 2020 23:31:20 +0000 (UTC) Received: from localhost ([::1]:57884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inWPX-0006uM-9j for normalperson@yhbt.net; Fri, 03 Jan 2020 18:31:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57459) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1inWPQ-0006uF-Tg for bug-gnulib@gnu.org; Fri, 03 Jan 2020 18:31:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1inWPP-0001Hf-Q3 for bug-gnulib@gnu.org; Fri, 03 Jan 2020 18:31:12 -0500 Received: from mail-wm1-f52.google.com ([209.85.128.52]:40416) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1inWPP-0001Gt-KC for bug-gnulib@gnu.org; Fri, 03 Jan 2020 18:31:11 -0500 Received: by mail-wm1-f52.google.com with SMTP id t14so9914741wmi.5 for ; Fri, 03 Jan 2020 15:31:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6CbXAQ65VYf4fsrYP5xyAOhT3PB8uBUicG4taQFYRpM=; b=oP1bg2xgMF6vdypA37+azX+lWU8kTu7kbLq9aChLnAy2JADpy3WX+9jpSFqRQK/KVB OY3RrUGH9wZUzU5SreHIx0AwEkVlJBByuKQoyLUBW9WWLIRo/y1nM3f2D0cHnWLy0uGJ lzl9ENqVeMDF44kmy3EOOjiOqxOTCpSrwbby24GHcYQz5plGNwhn28eJEA9G7eFLsN6u S+HpELFDv7v2lona4ihW1I2P+DknKjE4YfR0Lpask5SG99cE+NL7eiL+ZsjozKBin006 3HXrqIWq0/amwYc7w70tgXveJbBiIlkAWO1H/Gx4FpqzWq6HmBvCSTCp+WCbbYjkMJxh hFnA== X-Gm-Message-State: APjAAAWYWv1metxiyz8hUBfSXi69DG4epOfsPDyXZheW01/nWREk47K5 GrFheMag7A2zHjgFYoPujiTguo5iapzgo/hm0VM= X-Google-Smtp-Source: APXvYqwbT2rqi8QXZfu616VkD84ZPpYRv8IiX2rHWt+Joyi3N15gca7MIiQvM+nzihhy+LlIW7iLX+sR9DJVp9FryqY= X-Received: by 2002:a1c:18e:: with SMTP id 136mr22434827wmb.53.1578094270193; Fri, 03 Jan 2020 15:31:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jim Meyering Date: Fri, 3 Jan 2020 15:30:58 -0800 Message-ID: Subject: Re: Your gnulib patch To: Cong Wang Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.128.52 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "bug-gnulib@gnu.org List" Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Fri, Jan 3, 2020 at 2:43 PM Cong Wang wrote: > > On Wed, Jan 1, 2020 at 7:41 PM Jim Meyering wrote: > > > > On Tue, Dec 24, 2019 at 11:13 AM Cong Wang wrote: > > > Hello, Jim > > > > > > We found your gnulib patch > > > (http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=47cb657e) > > > quite useful for us, as we encountered a same issue with a few million > > > files under one directory. > > > > > > Is it possible for you to integrate the patch to glibc too? Our > > > project doesn't use gnulib at all, so it would benefit more people if > > > you could integrate it to glibc. :) I understand that would bring you > > > more work, if I have your permission, I can help on that too. Please > > > let me know how you would like to proceed. > > > > Hi Cong Wang, > > > > Thanks for your interest and the offer to contribute. > > > > If you'd like that functionality in glibc, note that it would have to > > use different function names, because the gnulib version of fts uses a > > different API (e.g., numerous struct changes were required to remove > > limitations in the glibc version). > > I understand I need to add at least ->fts_dirp to FTSENT in glibc, > but this seems fine as long as we only append to FTSENT? Users > should only dereference those documented fields of this struct. > Or am I still missing anything here? There are other required new members, e.g., to avoid O(N^2) effects, where N is the depth of the tree, and a 2^16 limit on the depth of a tree. Adding a new API to glibc is a big project. I suggest that you reconsider using gnulib.