Why is glibc not extensive?

[Xi Ruoyao]

On Thu, 2022-11-17 at 16:24 +0530, A wrote:
> On Thu, Nov 17, 2022 at 3:16 PM Xi Ruoyao <xry111@xry111.site> wrote:
> > 
> > On Thu, 2022-11-17 at 12:05 +0530, A via Libc-alpha wrote:
> > > Hi,
> > > 
> > > 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.
> > 
> > Because it will save more man hours by implementing them in a separate
> > library.  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.
> > 
> 
> 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.

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