Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My review of the C standard library in practice

nullprogram.com

Post reply on HN
Print view View original

61–70 of 94 posts

Re: My review of the C standard library in practice

#61

Post by icedchai »

marssaxman wrote: post #54
wheelerof4te wrote: post #47

What are the alternatives to these libc functions? Making C even more bare bones than it already is makes no sense.

It's not as strange as you might think. Back in the classic Macintosh era (pre-OS X), it was quite common to write programs in C which essentially ignored libc. It was not a Unix system, so C's filesystem API made for an awkward fit, and the system's native callback-based IO was more efficient anyway. For similar reasons Mac programmers had little use for C's string functions or its allocator. Nor was there any termi…

I learned C on the Amiga, and similar patterns were often followed. Example: we generally used the platform-specific AllocMem instead of malloc, even though a mostly complete C library implementation was available. One reason was AllocMem gave you finer control of what sort of memory was allocated (Amiga had "chip" memory, "fast" memory, and other oddities I now forget.)

Re: My review of the C standard library in practice

#62

Post by zellyn »

marssaxman wrote: post #55

I wonder what a reasonably modern C library would look like, were we to design it from scratch?

The last paragraph reads:

> If you would like to see interesting innovation, check out what Cosmopolitan Libc is up to. It’s what I imagine C could be if it continued evolving along practical dimensions.

Re: My review of the C standard library in practice

#63

Post by tialaramex »

adrian17 wrote: post #40

> As with volatile, C is using the type system to indirectly achieve a goal. Types are not atomic, loads and stores are atomic I don't get this argument. This same wording can actually be used to make pointers untyped: "pointers are not inherently typed, loads and stores are typed. (In fact, LLVM IR recently made pointers untyped too)". And yet, clearly there's value in having them typed at the language level. Simila…

These type qualifiers cause the opposite foot gun. The programmer confidently writes compound assignments, which look like they're atomic/volatile thanks to the type qualifier but of course they are not.

With intrinsics you don't have that problem. You just can't write the compound assignment - it doesn't exist, whereas in C it is just quietly compiled to two separate operations.

C++ 20 deprecated this nonsense, but at almost the last opportunity WG21 voted to un-deprecate for C++ 23.

Re: My review of the C standard library in practice

#64

Post by nicoburns »

krelian wrote: post #53
kstenerud wrote: post #52

Earlier quoted context omitted.

Well, that and also a showcase of just how BAD the design of the C stdlib string functions was, and continued to be with every iteration where someone introduced a new bad-and-poorly-thought-out API to replace the old bad-and-poorly-thought-out API. It still boggles the mind how a function that leaves a C string potentially unterminated ever even made it into the standard...

>It still boggles the mind how a function that leaves a C string potentially unterminated ever even made it into the standard... Easy to say with 50 years of hindsight. These are the pioneers we are talking about here. It boggles the mind how much they got right.

> Easy to say with 50 years of hindsight. These are the pioneers we are talking about here.

Eh, well kinda. Languages with decent string handling predate C, so it's not like there wasn't precedent to follow. The creators of C were pioneers, but they were also people who favoured a quick, hacky approach over a clean careful one. That has certain advantages, but it's rather unfortunate that C has become so foundational and we've been stuck with those hacks.

Re: My review of the C standard library in practice

#65

Post by tialaramex »

kstenerud wrote: post #57
krelian wrote: post #53

Earlier quoted context omitted.

>It still boggles the mind how a function that leaves a C string potentially unterminated ever even made it into the standard... Easy to say with 50 years of hindsight. These are the pioneers we are talking about here. It boggles the mind how much they got right.

While strcpy is forgivable considering it came from the primordial soup, there is no excuse for strncpy since it was designed to solve the problems with strcpy. And the string library is full of gaffes like this.

No, strncpy is not "designed to solve the problems".

strncpy is a function to fill out fixed size data structures such as some on-disk data structures, with a variable length string it right pads the structure with null bytes.

It does exactly what it was supposed to do, something that was pretty useful in 1970s UNIX programming but rarely if ever what you need today.

Re: My review of the C standard library in practice

#66

Post by amelius »

celeritascelery wrote: post #2

This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.

You can make new functions while keeping the old functions, but making them print a warning that they are obsolete now.

Re: My review of the C standard library in practice

#67

Post by flohofwoe »

celeritascelery wrote: post #2

This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.

> but libc needs to keep the same API

The "needs to" is debatable. Compared to the C++ stdlib, the C stdlib is so small that adding a modernized and incompatible "v2" next to "v1" is realistic. The effort could start as a 3rd party implementation similar to MUSL.

The old headers with the old APIs would still exist for "legacy code" but would generate "deprecated" warnings.

Once that new "3rd party stdlib" has proven itself in the real world, the C commitee might consider it for inclusion in the standard.

Re: My review of the C standard library in practice

#68

Post by stephc_int13 »

flohofwoe wrote: post #67
celeritascelery wrote: post #2

This just goes to show how hard it is to create a API to last 30 years. So much has changed since then, but libc needs to keep the same API. Things like Unicode and the internet (which brought the need for security to forefront) have come into popularity since then, but you can’t fix the old functions.

> but libc needs to keep the same API The "needs to" is debatable. Compared to the C++ stdlib, the C stdlib is so small that adding a modernized and incompatible "v2" next to "v1" is realistic. The effort could start as a 3rd party implementation similar to MUSL. The old headers with the old APIs would still exist for "legacy code" but would generate "deprecated" warnings. Once that new "3rd party stdlib" has proven…

Would you keep the naming style?

Re: My review of the C standard library in practice

#69

Post by flohofwoe »

nicoburns wrote: post #64
krelian wrote: post #53

Earlier quoted context omitted.

>It still boggles the mind how a function that leaves a C string potentially unterminated ever even made it into the standard... Easy to say with 50 years of hindsight. These are the pioneers we are talking about here. It boggles the mind how much they got right.

> Easy to say with 50 years of hindsight. These are the pioneers we are talking about here. Eh, well kinda. Languages with decent string handling predate C, so it's not like there wasn't precedent to follow. The creators of C were pioneers, but they were also people who favoured a quick, hacky approach over a clean careful one. That has certain advantages, but it's rather unfortunate that C has become so foundational…

What would those languages be? I'm only used to relatively modern languages with "decent string handling", but they almost always treat strings as opaque high level objects with dynamic memory allocation under the hood. Such an approach wouldn't exactly fit into the C philosophy.

Also, once UNICODE is added to the mix (which involves a lot more than just the text encoding), a decent string processing library isn't exactly trivial, it either needs a very big chunk in the stdlib, or a a handful of specialized 3rd party libs).

Even in Zig, which has a very decent modern low-level approach for handling string data, people used to high level string objects would probably be shocked at how 'inconvenient' it is to work with string data (which can be solved with specialized libraries though).

Re: My review of the C standard library in practice

#70

Post by naasking »

zellyn wrote: post #62
marssaxman wrote: post #55

I wonder what a reasonably modern C library would look like, were we to design it from scratch?

The last paragraph reads: > If you would like to see interesting innovation, check out what Cosmopolitan Libc is up to. It’s what I imagine C could be if it continued evolving along practical dimensions.

I found that sentence weird because when I checked Cosmopolitan, it included most if not all of the functions this article was claiming shouldn't be used.
Post reply on HN