Same as with stdlib++ btw, where strings are now uselessly bloated and most data structures are getting useless also.
Where are utf8 strings? u8"" constants only is for nothing. Everybody needs an u8 api.
Where are the secure _s extensions? Pickering about callbacks and Microsoft is all they can do. But they rather add env hooks. __bos/alloc_size support is getting better, but gcc still cannot do proper usable const expressions in C. It's a nightmare.
You still cannot compare strings, even not with the crazy wchar_t strings (size 2 or 4), nobody uses anymore. wcscmp only compares buffers, but not strings according to the unicode rules. I believe strings would be pretty important to support, not?
What about a fast malloc? Not even ptmalloc3 went in, there's still stone-age ptmalloc2.
double-close leads to crashes, really? Similar to freopen with NULL.
This is your great community consensus. BSD or even musl are far ahead.
You have a source for that? it wouldn't surprise me, GNU code tends to be more bloated than a similar BSD licensed project.
But recently also bos and align_size support got better in other libc's, which do use clang and not gcc. gcc sucks big time with those optimizations. freebsd and darwin all use clang. This is in the ~60% ball figure.
The size of dynamically allocated malloc'ed structures, not just constants. The majority of pointers have an alloc_size, but no object_size (i.e. bos: __builtin_object_size).
The community spoke and said they did not like dictators in development of glibc. Since Drepper's removal, many would agree that the quality of glibc has increased significantly. RMS is well aware of this and the delicate political situation. He should recognize that coming in and declaring himself in charge would not play well with a community that stated about their maintainers following Drepper: "This does not confer any extra ability to make decisions for the project; community consensus is what matters there."
[0] https://sourceware.org/ml/libc-alpha/2012-03/msg01040.html