Why is glibc not extensive?

[Xi Ruoyao]

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 <xry111@xry111.site>
> > wrote:
> > > 
> > > 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.
> > > 
> > > 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.
> > 
> > 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.
> 
> Copying from Glibc to another project (which is not under GPL or LGPL)
> is not allowed by LGPL.
> 
> 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).

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University