>>31
Nope. It just means that the C standard library is _small_. Contrast with Java, where you have a standardized GUI library... no, wait, _two_ standardized GUI libraries because AWT turned out to be overengineered and slow as shit for 1998 computers.
The C standard library has tools for working with the standard datatypes provided by the C language, and for basic I/O functions. Can you believe that they actually criticized C stdlib for assuming a files-and-directories view of persistent storage? Some dissed it for only supporting linear, byte-addressed files; mainframe programmers were used to storing fixed-length records in more setup-heavy files, where the record boundaries were enforced by the OS.
Linked lists and string buffers you can do yourself. They're just a combination of structs and pointers, and structs, pointers and a len/size combination, respectively. Nothing about them is a standard data type, and there's literally tens of ways to do e.g. linked lists; therefore it doesn't suit a low-level language like C to have a standard library that forces everyone into the One Single Collections Interface.
>>29
You call that slow as shit? Consider Java, where strings are immutable and concatenation consists of an allocation from a GC heap, an object creation thing (set up vtables etc), a copy and then another copy. Do that five or six times, as with the usual
System.out.println() call, and you're ankle deep in GC shit already.
Seriously dude, if in doubt or jonesing so hard for "performance" use
strlen() and
memcpy() and set the damn null byte yourself. Of course this is neglecting that just one mispredicted branch will cost you about as many cycles as filling in 32 zero bytes would... L2 cache misses are even worse.
And don't get me started on the fucking "better string library". That shit doesn't cover half the cases where null-terminated strings rule the skies, but it still somehow manages to have Constructor Disease.
What I see in these C-hatin' comments is people who don't have experience in using C for reals. Instead, you'd rather have something that had the speed and readability advantages of C but somehow was your Ideal Language. Surprise surprise, that doesn't exist. Rather, we use the tools which exist in the real world and are proven to work. Would you go crying to the hammer manufacturer when you struck your thumb with one, that the standard hammerhead sucks because it doesn't have a groove the shape of your thumb so it'd have been safer? Getting burnt on a hot stovetop has one effect on smart people (besides the second-degree burn): the smart person learns to watch himself around hot stovetops.
If it's thick protective gloves you want, go back to Java or C# and hope really hard that the runtimes one day advance to a stage where they're "as fast as C" 90% of the time. Or that by the time your great big ambitious project is release-worthy, hardware will have mitigated the performance effect.