From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 9AA5F3982407 for ; Thu, 17 Nov 2022 11:19:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9AA5F3982407 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1668683979; bh=LltATwfiqOD78+oFLKT7bckYn71H06RONVg8vunsCzw=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Y4uB0uFR3O2JP5cahuQgnYNKKjhW+H1bcbLHHAYMNL0zhbuaqx0NSmSiAhcPoIQzz 6uL8qMnASKw/FUT2FYheCoMSnae3FgfUBxukzrUEx2j3vX3eqMQb2AQKcGHUwkqLNu BrXEkj6or/ncykR0Bzc6oAUSWwHXLzlSABau3tlo= Received: from [IPv6:240e:358:1127:2800:dc73:854d:832e:3] (unknown [IPv6:240e:358:1127:2800:dc73:854d:832e:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id F206366791; Thu, 17 Nov 2022 06:19:36 -0500 (EST) Message-ID: Subject: Re: Why is glibc not extensive? From: Xi Ruoyao To: A Cc: libc-alpha@sourceware.org Date: Thu, 17 Nov 2022 19:19:29 +0800 In-Reply-To: <831230ff0b357c92178c128c99da69788171e84b.camel@xry111.site> References: <3a62e9dd71c1e542e38d6444c955a44185e07936.camel@xry111.site> <831230ff0b357c92178c128c99da69788171e84b.camel@xry111.site> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 MIME-Version: 1.0 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROM_SUSPICIOUS_NTLD,LIKELY_SPAM_FROM,PDS_OTHER_BAD_TLD,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 2022-11-17 at 19:13 +0800, Xi Ruoyao via Libc-alpha wrote: > On Thu, 2022-11-17 at 16:38 +0530, A wrote: > > On Thu, Nov 17, 2022 at 4:29 PM Xi Ruoyao > > wrote: > > >=20 > > > On Thu, 2022-11-17 at 16:24 +0530, A wrote: > > > > So, do glibc developers also take care of musl, msvcrt, etc.? I > > > > didn't > > > > know this. And if not, then why would glibc developers bother > > > > about > > > > other libc implementations. > > >=20 > > > Because if the fancy features are supported by Glibc but not other > > > libc > > > implementations, the programmers will likely re-implement the > > > feature > > > anyway because they want there program functional with different > > > libc > > > implementations. > >=20 > > They will not implement again. They will copy from glibc.Currently, > > everyone is implementing their own and using lots of man hours. > > Copying is 5 minutes job. >=20 > Copying from Glibc to another project (which is not under GPL or LGPL) > is not allowed by LGPL. >=20 > So why not just post your implementation and tell others to copy from > it? For example there is already https://c-util.github.io/c-rbtree/ It's dual-licensed with Apache license so there will be no license problem to copy from it. If you don't need to hack the code you can also just link to this library. If a project is not using this library, it's either (1) In this project AVL tree (or something) performs better than this RB tree implementation; (2) The maintainer is stupid. (3) The maintainer just loves to reinvent wheels. Adding an rbtree into Glibc won't resolve any one of (1) (2) (3). --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University