From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 495003858414 for ; Wed, 8 Sep 2021 11:57:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 495003858414 Received: by mail-qt1-x82b.google.com with SMTP id w17so1535702qta.9 for ; Wed, 08 Sep 2021 04:57:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EkftHxphkEGTsYrO0KbGPkM4s0wtST5sbYfBKSgrTqg=; b=AImyhn6At45EboVd6Q/ZMtYsTw3vU56juzWc594hYqEu16X2Pt1Q/sAHTsPah6w3HP tapR5mWFCM/lP1lfVDhbZv4BrVgvGAhRHIERmJ3vps6iFLl6ETkwnuZQnZhAxlVu4ec9 VSH8twV3+jUl6yDEfERGWVig6svF7EcMFO4fJJH9mE2gafjIiC/YQYYytZ+F/v4EktnY chf+XYxgDscPcBDLgvfNG8BvF/LiTzXav9STZFm3eMy2xJ+Ulor0yjQBRsWqriBiVKJZ C0kxX1xCq8xiFpl14i3OP5pr4JaK+vB9EsPvGl8zJA9n4F7SxeQk9uh5MVOea50Ik4Sp lrtA== X-Gm-Message-State: AOAM531M8Jq7wKHESlGABYdta33eT9n1Jxy2z4ljk10jSwTXS6iBDZQS 1ONrwmryv3F6nMV3IqWOnUkntLtgblmH2A== X-Google-Smtp-Source: ABdhPJyLDPhnbhhlv1Eo7g6OeQWCMyo+MK1drZ7PNgerK9sqP8GB5u0+lGdrozyQtll7pWuJsoDhcA== X-Received: by 2002:ac8:6bd0:: with SMTP id b16mr3317213qtt.375.1631102221669; Wed, 08 Sep 2021 04:57:01 -0700 (PDT) Received: from ?IPv6:2804:431:c7cb:733d:7748:fda0:30fe:10ff? ([2804:431:c7cb:733d:7748:fda0:30fe:10ff]) by smtp.gmail.com with ESMTPSA id v7sm1518755qkd.41.2021.09.08.04.57.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Sep 2021 04:57:01 -0700 (PDT) Subject: Re: [PATCH v3 0/7] Use introsort for qsort To: Paul Eggert , Carlos O'Donell Cc: libc-alpha@sourceware.org References: <20210903171144.952737-1-adhemerval.zanella@linaro.org> <3d2c0890-7a7e-518e-d39e-e3b0df85dd94@cs.ucla.edu> <54a8f384-dfe4-db41-a09e-2209e0e62478@cs.ucla.edu> <6e9bbf08-4a76-6d33-1319-abda26a19692@linaro.org> <9d8c44d4-4112-4bfe-0ad8-0504e70665ec@cs.ucla.edu> <1a79a7d6-fdaf-c046-d5bf-28fa765df125@linaro.org> <31ead1a4-63b2-6134-a094-0077159a9595@cs.ucla.edu> From: Adhemerval Zanella Message-ID: Date: Wed, 8 Sep 2021 08:56:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <31ead1a4-63b2-6134-a094-0077159a9595@cs.ucla.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 11:57:03 -0000 On 07/09/2021 16:28, Paul Eggert wrote: > On 9/7/21 11:07 AM, Adhemerval Zanella wrote: >> we are providing >> async-safeness depending of the input arguments (which is really a >> bad interface). > > Many functions are async-signal-safe for some arguments but not others. The 'free' function is just one example. qsort is not at all unusual in this department. This sort of interface is "really bad" only in the sense that every function that is not async-signal-safe is "really bad". My point it is confusing and leads to bad assumption from users, as ruby shows. > >> My point is blocks neither closures are essential to provide different >> sort algorithms with different strategies and constraints. > > If that's the point, then I disagree. qsort_r is there for a reason, and this reason applies to any sorting algorithm. Some callers can limp along without qsort_r, by writing code that is not thread-safe or whatever; but many callers really need qsort_r and a similar need would apply to any sorting algorithm. I think you missed my point here, I was not advertise to not provide a qsort_r like, but rather that the blocks extensions from BSD is just an extension. > >>> > Would you like to work together to come up with a new API that addresses both of our concerns? >> I am not against your suggestion > > That's a good way forward, then. Do you have an API in mind? If not, I can propose one. Sure, but this is orthogonal to the change I am proposing here. May we move forward in this direction first?