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 CA7CC394243F for ; Thu, 17 Nov 2022 10:59:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA7CC394243F 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=1668682781; bh=CkM13tEym7oYh0L53R0y53GweOTR7JQlHOuBMrd5sbk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=KpUgSso8hxCFC+WxJEHAAmayzMC8kHD1/IfC7RQpN/fSolEQXmQ5XL1TELQ+vANB0 AxAgp6Aci0Q7+vMX+ZLBqNXqGBFepXJyzTJUrYdKzWTiHFbqqeZH+ABrNPrZWurcQQ NhblPywbCWvzQkSPGrxvR0op7jTc1q9tkRpUfPpU= 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 3013C6676B; Thu, 17 Nov 2022 05:59:38 -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 18:59:31 +0800 In-Reply-To: References: <3a62e9dd71c1e542e38d6444c955a44185e07936.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 16:24 +0530, A wrote: > On Thu, Nov 17, 2022 at 3:16 PM Xi Ruoyao wrote: > >=20 > > On Thu, 2022-11-17 at 12:05 +0530, A via Libc-alpha wrote: > > > Hi, > > >=20 > > > In my opinion, glibc should have support for maps, sets, balanced > > > binary trees, many more string functions, etc. (I know tree and hash > > > are there in glibc), so that developers don't have to implement them > > > themselves, thus saving lots of man hours all over the world. > >=20 > > Because it will save more man hours by implementing them in a separate > > library.=C2=A0 You can link the library against any libc (glibc, musl, > > msvcrt, binoic, the libc on Mac OS X - I can't recall the name, ...) > > instead of adding the implementation into all libc implementations. > >=20 >=20 > 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. 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. > So, implementing a balanced binary tree in 10 - 20 libraries will > consume more man hours than thousands of programmers around the world > trying to implement balanced binary tree in their C projects? I don't > believe this. It will consume more man hours than implementing a balanced binary tree as a separate library and link all these projects to the library. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University