Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

I wish we could do away with (parts of) libc entirely. Many of its design principles and limitations date back to its inception and don't make sense today, even on "embedded" systems.

- function names limited to 6 characters (because of compiler/linker memory limits at the time?)

- non-reentrency of many functions (strtok(), errno...)

- dangerous string manipulation functions (see the various iterations of strcpy())

- and so much more...

Of course, I'm missing the point. Libc continues on because it's standard and backwards-compatible, and lets you leverage 50 years of software ecosystem.

Nevertheless, I'd love to see what a modern clean-slate implementation might look like. I'm sure there'd be much disagreement about what warrants replacement and what doesn't ;)

View on HN

> I'm sure there'd be much disagreement about what warrants replacement and what doesn't ;

How many backwards incompatible variations of C++ std::string have there been, simply in terms of the standard (not extensions). Two? Three?

glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around).

A good string interface is impossible to pin down because a "string" is the anti-thesis of a proper data structure. C dipped its toes in the better string library waters with Annex K, which saw almost no uptake; even the original sponsor, Microsoft, never shipped a complete implementation. C would be wise to avoid chasing the mirage of a better string library. In general if you're thinking in terms of "strings", C is the wrong language. C being an inconvenient language for programming with that mindset is a good thing.

(I would love to see strlcpy added, but the fact it's so divisive is maybe a strong hint that there's no way to placate a substantial minority of people, not even the most pragmatic of users. Anything involving the str* API is a lose-lose at this point.)

What C really needs are some primitives for bounded arrays and slices. There are some very good, very simple proposals out there, but no compiler vendor has actually shipped them and the C committee has been burned several times before by standardizing de novo interfaces.

> even the original sponsor, Microsoft, never shipped a complete implementation

I guess mostly because they decided that in what concerns improving Windows system programming safety they were better moving everything into C++ and let others keep bothering with C.

And nowadays their are eyeing into the C#, C++ (with Core Guidelines analyzers) and Rust.

The exception being Azure Sphere, but I bet they will eventually add Rust there, as using C taints the security story of Azure Sphere.

The resistance among C devs to move away from micro-optimize every line of code while writing it down is too big to ever adopt one of those primitives for bounded arrays and slices.

Leading to solutions like ADI enabled SPARC Solaris, or the future Android devices that will be coming with ARM memory tagging enabled.

Regarding strlcpy and co https://developers.redhat.com/blog/2019/08/12/efficient-stri...

> glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around).

  snprintf(destination, sizeof(destination), "%s", source);

?

snprintf(3) can fail with ENOMEM. In fact, at one point (not sure about now), glibc could fail with ENOMEM even for %s.[1]

The size argument is an int, not size_t, so there are arithmetic overflow problems.

The return value is also an int, creating underflow and overflow hazards, though the degree to which this is a problem, and the extent to which it's a feature, vary. Everybody has a different opinion about how truncation should be signaled, if at all.

[1] Because glibc snprintf uses (or at least used) its stdio FILE interfaces for implementing snprintf, and it conditionally uses malloc for initializing a temporary FILE object.

You also missed the part where it's not necessarily self-evident what it does, or that it even fixes the issue ;)

errno is thread-safe as it resides in TLS. Part of libc such as pthread is very hard, and so does the dynamic linker. The latter is supposed to handle TLS data as required by TLS/elf spec, which more or less requires a full thread/pthread implementation. As a result, it is rather difficult to break down libc, without writing the whole thing in the first place. golang might be an exception (no linkage against libc), but AFAIK it doesn't use TLS.

It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking).

Neither pthreads nor a dynamic linker are required for libc. pthreads is part of the POSIX standard, not the C standard, and many libc implementations over the years have not supported dynamic linking.

To give you an idea, here's a chip used by at least one of the products developed by the author:

https://www.st.com/en/microcontrollers-microprocessors/stm32...

16KB of ram. You're not going to see any linking on this because you're probably running everything in a single address space anyways.

What is TLS?

> Part of libc such as pthread is very hard, and so does the dynamic linker.

What does this mean? I'm having trouble parsing this as English much less making sense of the argument :)

> It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking).

Why does libc ship with string functions in the first place? What is special about strings that they are included in libc while other data structures (to my knowledge) are not? Presumably you don't need strings to implement malloc or other parts of libc?

> What is TLS?

Thread-Local Storage:

https://en.wikipedia.org/wiki/Thread-local_storage

Strings ship with libc because pretty much every language ships with string manipulation routines. You need them to basically do anything that isn’t pure computation.

Granted, but pretty much every language also ships with routines for other data structures, and I would think that you need things like lists/slices more often than you need string routines.

libc includes string functions because C requires string manipulation functions. Other languages may or may not make use of C's string functions.

Yes, because they ship with their own string type.

strtok_r() should be available on any halfway decent embedded platform.

musl?

musl still has many of the same issues, as it needs to remain compatible with POSIX.

Reply on news.ycombinator.com