Why is glibc not extensive?

Why is glibc not extensive?

[A via Libc-alpha]

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. This
will also make C more user friendly like C++ and Java.

Amit

Re: Why is glibc not extensive?

[Xi Ruoyao via Libc-alpha]

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.

> This will also make C more user friendly like C++ and Java.

Glibc just contains one implementation of C standard library, it's not
"the reference implementation": there is just no such a thing in the
world.  The proposal of changing the spec of C language or standard
library should be sent to WG14, not here.

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

Re: Why is glibc not extensive?

[A via Libc-alpha]

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.

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.

> Glibc just contains one implementation of C standard library, it's not
> "the reference implementation": there is just no such a thing in the
> world.  The proposal of changing the spec of C language or standard
> library should be sent to WG14, not here.

Hmm...I will see if I can contact them. I searched on Internet but
couldn't figure out who is the right person to contact for this. Do
you know who should I contact?

Amit

Re: Why is glibc not extensive?

[Xi Ruoyao via Libc-alpha]

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

Re: Why is glibc not extensive?

[A via Libc-alpha]

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.

Amit

Re: Why is glibc not extensive?

[Xi Ruoyao via Libc-alpha]

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?
-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: Why is glibc not extensive?

[Xi Ruoyao via Libc-alpha]

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