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 0AA891F463 for ; Wed, 8 Jan 2020 01:44:00 +0000 (UTC) Received: from localhost ([::1]:58640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ip0O6-00037F-Ds for normalperson@yhbt.net; Tue, 07 Jan 2020 20:43:58 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52513) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ip0O2-000373-39 for bug-gnulib@gnu.org; Tue, 07 Jan 2020 20:43:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ip0O0-0007Du-Ry for bug-gnulib@gnu.org; Tue, 07 Jan 2020 20:43:53 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:35707) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ip0O0-0007D5-M2 for bug-gnulib@gnu.org; Tue, 07 Jan 2020 20:43:52 -0500 Received: by mail-wr1-f48.google.com with SMTP id g17so1684783wro.2 for ; Tue, 07 Jan 2020 17:43:52 -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=ACPg6rrJKrvkck5ijty0RLLWpNRHTu5cABUPG/xD3j8=; b=DPC5Hljj0IJUH+Hj8ceo1QvBkmVSwnsvCTEL8slVRqSf3Sa2Ik2xJ6QhbShCRp2Z6O Ay72+i97zSA2ZQqhq0x5n8vH/UY3TTnuF7AQwX2734fcbODp+xUPkX6/Vt5f67rODeXc d4H76teAvGm49ur/kEkzvPTxJosIHtLPiCnrUJcKS29HGJBIcZaSv6pRb5NNw9xswtlb 8kneYjtrU6d4MhgCH3pD1rW1kYfI6NfzhZ6Ztvp4mr+djZpz4bbpdnpu4KBv9VcS6qha eat/mXA0GNqX3PZ+uwgFlC5xLOBOoTzH/Qo2fCtirFvbRhXfkn+ik2NZ919D5ZZZUe+2 XL8Q== X-Gm-Message-State: APjAAAXSUmN7dw9MAHqp/3VavPqRAOdtpFHAhhSuhToOBoo4RutQ3pv/ iJiJmvAuyY2JQE24JOA5VHvfmCLQVWjLu10s76c= X-Google-Smtp-Source: APXvYqyAvI+w1kOJ6dJjTrmIrtM1suQ5CsoqHwZ/GTvB0Hh7K8PiOODFW54F/r6b2l3OhFM+/6429mC2ru+M7nSINqg= X-Received: by 2002:a5d:670a:: with SMTP id o10mr1814773wru.227.1578447831250; Tue, 07 Jan 2020 17:43:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jim Meyering Date: Tue, 7 Jan 2020 17:43:39 -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.221.48 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 Tue, Jan 7, 2020 at 4:41 PM Cong Wang wrote: > > On Fri, Jan 3, 2020 at 3:31 PM Jim Meyering wrote: > > > > 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. > > I already advised my colleagues to build with gnulib to address > this issue, before email you. > > I am still trying to understand why adding new members to > FTSENT could break the API here. From my naive understanding, > appending to FTSENT is safe. Any hints? Changing FTSENT modifies the ABI, and that is a big deal and not justified here, so you must provide a new set of functions (new API) with functionality nearly identical to the fts* functions, but using the new struct.