Musl/uclibc cucks BLOWN THE FUCK OUT

can they ever recover?

Other urls found in this thread:

github.com/lattera/glibc/blob/master/string/strlen.c
twitter.com/NSFWRedditVideo

original source?

I'd rather have slightly less performance than a heap of disgusting CVE riddled bloat.

t. liblet

>still no support for static linking
>still no strlcpy/strlcat
>frequent nasty bugs
>massive memory footprint
>constant regressions
>autistic code style
>made by SJW faggots
GNU toddlers will defend this.

From Void wiki:
>Some programs (mostly graphical applications) will work incorrectly, or segfault when run under musl. This may be due to programs expecting some glibc-specific behavior.
>Also, some programs that rely on glibc-specific behavior cannot or at least have not been patched yet.
Clearly, Musl is incomplete. It needs to implement this critical functionality that is needed for programs to work. In its current state, it is unfinished.

I really wish they also listed examples.

so it's you again

oooor, musl is posix-compatible, but glibc has non-standard extensions (alloca, etc)?

You again. Please stop posting.

>glibc has non-standard extensions
How could glibc be non-standard? It's included in every GNU/Linux distribution. It's obviously the standard.

We've been over this.

>what is backwards compatibility?

every single musl thread he does this

Exactly! Where is it?
Glibc was started 30+ years ago. Musl started around 7 years ago.
Musl is the one missing backwards compatibility here. Missing compatibility with Glibc. The current standard.

Just say "I rather SUCK MORE" :^)

>literal bullshit
>literally 0 sources
sucksmore shills will back this.

>using glibc-specific features
>not using glibc build tag guard
classic

They didn't implement bugs so it must be incomplete. Bzzzt.

>Programs run fine on glibc
>Programs break on poosl
>somehow glibc is the buggy one
wew

the joke is majority of libc extensions in glibc come from 4BSD

>Compile attempt 1. Segfault, tweak a variable
>Compile attempt 2. Segfault, move this free() somewhere else
>Compile attempt 3, it works! Ship it. This means I must actually know what I'm doing and totally not just changing various shit around until it compiles and doesn't crash instantly.

So you admit that glibc is backwards.

Stop being a retard. OpenBSD has the same problem, and it's because programs are poorly written and glibc is too lenient with shit code.

sooo... plan9?
plan9.

snail9

>OpenBSD has the same problem
No it doesn't, you can just use gcc.

Wow, you're clueless.

But honestly while you are switching to things that work better you may as well swap out the userland and kernel too.

>weaboo, tripfag and retard
l٥ﻻ ﻉ√٥υ

This has nothing to do with what it is responding to.
No. Through enhancements and extensions over the years, glibc has added features and functionality. This is very forward-thinking.
Poorly how?

>Poorly how?
he doesn't know

systemd is also a standard, then, surely? sysvinit just has to implement the missing extensions

glibc > *

Musl is too tied to linux to make it useful

The libc needs to directly call kernel syscalls.
You can't really make it portable.

*uses a portability layer*

...

m-muh bloat!
no, illumos

Correct, and they, for the most part, have been implemented through the forking and development efforts of the Gentoo project (udev and eudev for example)

No, thanks. Enjoy your buffer overflows.

This comparison is very outdated, look at musl and glibc versions, you better use the one linked at the musl site.

>-O0

you just clearly proved you have no idea what it is you're talking about

>that pic
>it's real
>github.com/lattera/glibc/blob/master/string/strlen.c
wtf.

>github.com/lattera/glibc/blob/master/string/strlen.c
How has someone not gone back and fixed that?

(You)

>glibc programs run fine on glibc
really gives me a think