Replacement for C standard library: your wishlist?

[Nominal Animal]

I've been thinking about writing my own systems programming library, to use instead of the standard C library, under Linux (and possibly other OSes, at least *BSDs).

As you probably know, the C programming language is actually defined separately for hosted environments (full standard C libraries available) and freestanding environments (standard C library not available, with only <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h> headers available).

I am thinking of writing a new support library from scratch, replacing the standard C library, but exposing the same (Linux/POSIX) concepts, but without the historical baggage of standard C library functions.  In essence, applications using this library will be compiled freestanding.  Note that this is a general-purpose systems programming library – for daemons and such –, not a tightly-constrained embedded one, so dynamic memory allocation will be heavily used.  (I am completely fed up with line length limitations stemming from fgets() when POSIX getline() exists, in particular.)  Most of the POSIX syscall functions (getpid(), getppid(), clock_gettime(), read(), write(), and so on) will be exposed using their traditional names, but probably without errno, i.e. if an error occurs, the functions will return a negative error number, instead of setting a thread-specific errno variable to reflect the error.

While I have my own wishlist based on my own experiences, I'd like to know what others would really like to see in a C "standard" library, and especially why.  Many of you have encountered things I haven't, so I'd like to hear your thoughts on this.  My reason for doing this is simple: I want to know how much better we could do, if we wanted to.

[brucehoult]

I have some things that I actually implemented around a dozen years ago while helping to create a Java to native (ARM) compiler for the BREW phones that were common just before iPhone and Android came out. The phones then had between 40 KB and 4 MB of RAM. Sadly as it was proprietary and I'm a good boy I no longer have access to that work.

I used the same library to hand write code using C and it was very pleasant.

The #1 thing is to ban free() and base a C library on garbage collection. I disagree with Apple and prefer tracing over reference counting. The Boehm library work very well, with a few modifications -- I vastly reduced the amount of static memory needed and optimized the object size buckets and a number of other things.


The other big thing is to ban arbitrary large object allocations.

- Choose a maximum malloc() size which might be 256 bytes or 4K or whatever. This allows you to vastly decrease fragmentation by keeping pools of objects of every possible size -- and there are only a small number of possible sizes.

- larger objects are a fixed-depth tree of nodes of the maximum size (except for possibly the last node at each depth), with each node containing an array of pointers to the next level nodes. With a small machine or big maximum object size the tree might be only two levels, with one layer of pointers and the second layer being the actual user data.

- for example on a 32 bit machine with 64 KB maximum malloc size and 2-level tree, a composite object can have maximum size of a 64K node containing 16K pointers to 16K nodes of 64K each of user data. That is, the maximum size of user data in a single string, array, buffer etc would be 16384 * 65535 = 1 GB.

- because the tree depth is fixed for a given implementation of the library, accessing a data item is straight line code with no branching. To access byte n in an array of bytes pointed to by p:
  - check that n is less than the current array size
  - the integer you want is at p[n>>16][n&0x3fff]
  - this is one shift, one AND, and two memory loads. That's slightly slower than just a memory load, but not much, especially if the top level of pointers is in L1 cache but the main data isn't.
  - for small objects the top level of pointers is also small. e.g. if the object is less than 64 KB in size then the pointer layer is just a 4 byte object containing one pointer (or whatever malloc()'s minimum size is)

- if you want a smaller maximum malloc() size then a 3 level tree can use a 4 KB maximum malloc() size to address a layer of up to 1024 pointers to a layer with up to 2^20 (1048576) pointers, to a layer with up to 4 GB of data. If 512 MB is enough in a single variable then you can reduce the maximum malloc() size to 2 KB.

- the overhead of chasing two or three pointers to find your data only applies to random accesses. If you want to process data sequentially then you can use C++ iterators that usually do only one access for sequential operations, doing an extra memory access only when moving from one node to the next. In C you can use an iterator function that you give a callback function that takes a pointer to the start of a contiguous block and a length (and also a void *userdata for accessing an environment, intermediate results etc). This can be extended to iterator functions that take two or three trees and call callbacks with two or three pointers and a single length.

- it's handy if the top level of pointers is actually a descriptor with the current number of elements *and* a byte offset to be added/subtracted from the user's offset before using it. This allows allows things such as substring() or array slices to be done by sharing structure with the original object. Especially if all the nodes are garbage collected so if you take a few substrings from a huge buffer and then forget the reference to the original buffer then all the parts that aren't in the substring can get GCd

[Whales]

Make a single standard for the sizes of types and printf()-like format strings

Fix the size of int, long, char, etc; don't let them be platform specific.  In practice this means having to use different type names like stdint.h does (otherwise you break compat with other code & compilers),  I normally go for more sensible names like   u8, u16, u32, u64,   s8, s16, s32, s64,   f32, f64  (rather than things like uint32_t, uint64_t, etc)

This means implementing printf()-like functions to use '%d' to mean one specific datasize too.  In the current world we have to write things like "I have %"PRIu32" and %"PRIs64" cats" if we want to be exactly specific about our data sizes, which really sucks.  Even between glibc x86_64 and glibc arm(6?) the definitions of some 'long' variants (long long IIRC?) is different; let along between whole microcontroller families 

I basically always have to be specific about sizes, otherwise I start having to add if() cases when I deal with data saved in files or from over a network.  Fixing the sizes of types would make things much simpler and get rid of a lot of hidden gotchas.

(Technically we can also talk about struct packing & alignment on different platforms, but that's moving more into compiler territory rather than libc territory)

[Whales]

Saner string funcs

I notice your mention of fgets()

Checkout BSD's string funcs.  Notably I keep a copy of strlcpy() in my personal library, it's a much saner option than strncpy() and strcpy() (both are broken).  This is surprising for a lot of people because the string functions with 'n' in their name are typically the fixed options, but not in this case.

Sidenote: I've seen some projects bring in a whole linked libbsd dependency just to get this one func 

[Whales]

The #1 thing is to ban free() and base a C library on garbage collection. I disagree with Apple and prefer tracing over reference counting. The Boehm library work very well, with a few modifications -- I vastly reduced the amount of static memory needed and optimized the object size buckets and a number of other things.

I disagree here.  I think improvements to C should be made by making the language simpler and having less gotchas, especially in terms of simpler to understand & simpler to predict.  Garbage collection implementations always have corner cases and harder to predict behaviours (eg runtime slowdowns).

It's bad enough that dynamic memory allocation is already unpredictable, I don't want more of this 

[Whales]

The other big thing is to ban arbitrary large object allocations.

- Choose a maximum malloc() size which might be 256 bytes or 4K or whatever. This allows you to vastly decrease fragmentation by keeping pools of objects of every possible size -- and there are only a small number of possible sizes.

- larger objects are a fixed-depth tree of nodes of the maximum size (except for possibly the last node at each depth), with each node containing an array of pointers to the next level nodes. With a small machine or big maximum object size the tree might be only two levels, with one layer of pointers and the second layer being the actual user data.

Isn't this sort of what gets done anyway?  By the OS + memory mapper + memory controller/MMU?  A chunk of what appears to be contiguous memory from your program's perspective can actually be split up over all sorts of places and this gets internally tracked for you by some structures.

The method you describe to solve memory fragmentation sounds like pre-fragmenting everything.  Wouldn't a finer-grained MMU/similar achieve the exact same thing, but with better hardware acceleration?

[brucehoult]

The #1 thing is to ban free() and base a C library on garbage collection. I disagree with Apple and prefer tracing over reference counting. The Boehm library work very well, with a few modifications -- I vastly reduced the amount of static memory needed and optimized the object size buckets and a number of other things.

I disagree here.  I think improvements to C should be made by making the language simpler and having less gotchas, especially in terms of simpler to understand & simpler to predict.  Garbage collection implementations always have corner cases and harder to predict behaviours (eg runtime slowdowns).

It's bad enough that dynamic memory allocation is already unpredictable, I don't want more of this 

Garbage collection is faster than malloc/free. I can (and have) proved that by using LD_PRELOAD to replace the C library malloc with Boehm GC for a large range os programs, with the result that they finish sooner and/or use less CPU time.

That's even on programs that are completely ignorant of the fact they are now running under GC.

A properly-written GC can easily limit the maximum pause time to an imperceptible level.

[Nominal Animal]

The #1 thing is to ban free() and base a C library on garbage collection.

At the low level, daemons and such, I prefer pool allocators.  That is, having each allocation belong to a context, and being able to free an entire context.  This matches very well the needs of connection-oriented services, and also allows trivial implementation of per-connection memory use limits.

I am very ambivalent on GC.  If rock solid, it does eliminate a big swathe of possible bugs.  On the other hand, I've never found those bugs to be hard to avoid anyway.  I think it is slightly more higher-level concept than I'd like; the memory use overhead, especially in a service daemon, worries me.  Speed is not an issue, I know.  In any case, I'm not ruling either one out for now.

I do believe easy control of allocation limits is important, because typical Linux machines overcommit memory, and if it is easy for a service to internally control its memory use (with minimal code overhead), developers might actually use it.  In particular, if a service runs out of memory, I'd prefer it just drops a few connections, rather than die.

Make a single standard for the sizes of types and printf()-like format strings

Using u8/u16/s32/s64 as typedefs for uint8_t/uint16_t/int32_t/int64_t, sure.  Having printf()-like function with native formatting specifiers for them, definitely.
But, because this is C, and not a new programming language, we cannot restrict the size of say int or long.  We do need to stay within the rules of freestanding C, more or less.

There do need to be a couple of types that depend on the architecture, like size_t/ssize_t and uintptr_t/intptr_t.  But these should obviously have native formatting specifiers, just like size_t has (%zu) and ssize_t has (%zd).

Saner string funcs

Most definitely; strlcpy() (which ensures the target will contain an end-of-string nul byte), and also memfill(buffer, offset, size) which repeats the first offset bytes of buffer to the rest of the buffer, up to size; for example, to initialize floating-point vectors or structure arrays efficiently.  I also like strndup(), which is not in standard C (they're in BSD and POSIX.1), but is definitely useful.

Some of these are optimizations (memfill() definitely is), some avoid the horrible corner cases (like strncpy() not adding a string-terminating nul byte if the source string is long enough), and others make it easier to use better patterns.

For example, GNU and BSD provide asprintf(), which dynamically allocates the buffer to be formatted.  Very few programmers actually use it.  I'd prefer something along the lines of ssize_t my_printf(char **strp, size_t *sizep, const char *fmt, ...) with an interface similar to getline().  That is, to e.g. construct some complicated string, you might use

Code: [Select]

    char   *p = NULL;
    size_t  p_max = 0;
    ssize_t  p_len = my_printf(&p, &p_max, "foo-%s-%.3f", name, version);
(using current standard C library types here, for clarity).  This way, if one needs to construct such strings often, they can reuse the buffer, but still get it dynamically reallocated whenever it needs be.

I also dislike the interfaces that use static internal storage, and are therefore non-thread-safe (strtok() and so on).  BSD and GNU provide thread-safe versions, that point to either a prepared context variable (strtok_r()), or use dynamically allocated memory.

[PlainName]

I normally go for more sensible names like   u8, u16, u32, u64,   s8, s16, s32, s64,   f32, f64  (rather than things like uint32_t, uint64_t, etc)

Why is that? Wouldn't it be sensible to use what everyone else knows and understands? One could make an argument that using something else is like aliasing 'while' as 'whilst'.

[Nominal Animal]

I normally go for more sensible names like   u8, u16, u32, u64,   s8, s16, s32, s64,   f32, f64  (rather than things like uint32_t, uint64_t, etc)

Why is that? Wouldn't it be sensible to use what everyone else knows and understands? One could make an argument that using something else is like aliasing 'while' as 'whilst'.

Since we are talking about a new base library, why restrict to what everyone else knows and understands?

This is, after all, an attempt to discover what we could do better, not what everyone is already most comfortable with.

I do intend to provide a few macros of foreach_foo(...) format, for example to replace/augment ancillary data macros.
Say, foreach_msg_descriptor(fd, &msg) { /* fd is a new descriptor received via recvmsg(sockfd, &msg, flags) */ }.  These, too, will look oddly familiar but subtly weird to many, especially if you haven't looked at Linux kernel sources (which uses such macros to make many things much easier).

[PlainName]

Well, for backwards compatibility, ease of use and familiarity. Otherwise you might as well just do a complete language. Call it C+ or something. Hmmm, C#? Ah, D! Oh noes.... gotta be something not already sat on... D- then 

Edit: forgot a bit...

'Better' tends to drag along 'comfortable' with it. There have been many better mousetraps that dropped by the wayside because they were a pain to use, or just different enough that potential users could easily see the benefits. If it's a library it's going to be coexisting with already well-known libraries probably, and being the odd one out isn't a benefit. Where there is a common 'thing' it is usually sensible to use the common paradigm. I don't think that doing so would be detrimental to the kind of features you are all discussing, but I am willing to be told different.

[Nominal Animal]

If it's a library it's going to be coexisting with already well-known libraries probably, and being the odd one out isn't a benefit.

Because it is a replacement for the standard C library, requiring that C be compiled in freestanding mode, libraries developed against standard C will not be compatible.
Backwards compatibility is not an option.

I do not have any problems using uintN_t, intfastN_t, size_t etc. in C; I do so constantly.  However, I do have noticed a lot of C programmers avoid using them, and I wonder why.  Is it the type name, the _t suffix?  Or something else?

Like I said, I don't really understand why the _t suffix was added to these types.  It does not bother me per se; I just want to know how that suffix has affected the types' use.  Do they make it easier to read C code?  If they did, then shouldn't they be more popular by now?

Since <stdint.h> is available in freestanding mode, these types would be typedef'd to those in this library headers anyway, so it is not a question of either or –– except for which type names are used for function parameters and return values.  (But even those, the most common integer type is size, not a fixed-width integer type.)

I too am willing to be convinced otherwise, but familiarity is not an argument that sways me, because if it did, then there would be no sense in doing this at all; as the answer then would be to use the most popular subset of POSIX/BSD/GNU C.

[Whales]

Personally I don't use the official stdint.h names like int32_t and uint64_t for a couple of reasons:

1 or 2-letter differences (out of 8 or so letters) are hard to spot but make big differences.  "Hiding a tree in the forest" is not a good idea if the wrong type of tree is a possessed demon that eats your favourite numbers, so I prefer to have such trees standing on their own where everyone can make sure they're not lantana.  Compare how clearly words like int, long and float are differentiated at a brief glance.  Now look at the first line of this post and notice that one of the types I wrote was signed.

Of course I'm also lazy, typing u32 is much easier than uint32_t.  Words like 'int' are really easy to type, which is important, because you type them constantly in C code.

EDIT: I don't usually use the more advanced stdint.h types like int_least32_t and int_fast32_t; but I presume shortening these more corner-casey types might not be a good idea.  ie don't do il32 and if32

[DiTBho]

The #1 thing is to ban free() and base a C library on garbage collection.

GC is something that makes me perplexed. Probably because I have never understood how it works internally.

I have implemented my own version of malloc() and free(). I know how they work internally, and this makes me less perplexed.

[PlainName]

However, I do have noticed a lot of C programmers avoid using them, and I wonder why.  Is it the type name, the _t suffix?  Or something else?

Yes, that was essentially my question. The rest was just collateral

[PlainName]

1 or 2-letter differences (out of 8 or so letters) are hard to spot but make big differences.

That's a very reasonable view.

Actually, that's what I used to use too, but at some point I went with the flow. Can't remember when or why, now, though.

[Fixpoint]

I am thinking of writing a new support library from scratch, replacing the standard C library, but exposing the same (Linux/POSIX) concepts, but without the historical baggage of standard C library functions

To be frank, that doesn't make much sense. The C programming language is used BECAUSE of the standard. If you replace the standard with your own stuff, there is no reason to use C anymore. Then you are free to use much better, more modern programming languages.

During the last decade, much better options than C have been developed (including the embedded use case), for example D, Rust, or Go (I don't recommend Go, but of course I have to include it here). From a computer-scientific and software-development standpoint, C is bad from so many angles, I don't know where to start. So, if you don't want to use the old libraries anyway, why don't you look at the new languages? That would make much more sense than to carry this 1970's abomination further into the 21st century.

[Whales]

As a contrasting opinion: "modern" programming languages do indeed solve some problems, but they bring new problems to the table too.  They are not panacea, and small language/lib changes are just as valid as a path to experiment with as large language/lib changes (both with their own unique upsides & downsides).

The C programming language is used BECAUSE of the standard. If you replace the standard with your own stuff,

The 'C programming language' is only one part of C.  C is more than the official standards that compiler authors stand by.  It's a combined and universal effort that other ideas, languages and libraries get almost inevitably joined to in some way.

For a bit of perspective on this: standards like ipv4 in the internet are never going to be replaced, only joined to or extended.  Other new "replacement" or different protocols, like ipv6, get bolted on via things like ipv6-to-ipv4 bridges.  If you write an incompatible network protocol then someone, somewhere will inevitable write a bridge that converts it to ipv4 (or ipv6), hence joining it back to the universal internet.  You cannot replace, only add.

Does this mean creating ipv6 is bad?  Does it mean using ipx is bad?  Does it mean writing new C libraries is bad?  No.  It's a natural part of the evolution of both.

[Fixpoint]

As a contrasting opinion

Unfortunatly, that is not a contrasting opinion but a platitude without any information content. The fact that no technology is perfect, including the new ones, is obvious and neither has anything to do with nor contradicts the fact that it would be a good idea to replace C with better stuff.

The 'C programming language' is only one part of C.  C is more than the official standards that compiler authors stand by.  It's a combined and universal effort that other ideas, languages and libraries get almost inevitably joined to in some way.
(...)

Again, all of that has nothing to do with what I said. What I say is that C must be replaced with a safer technology that implements computer-scientific knowledge that has been commonplace for many decades now (it even was already known at the time when C was developed). Honestly, C's nonsense design is nothing that only I can see. So, there is no reason to discuss this further.

If you want to implement new libraries, fine, go ahead. If it's good stuff I would love to use it, BUT of course not in C. You are missing a chance here. Please don't promote C along the way but use a better technology. When we develop a new car, we don't use a steam engine for that. It's as simple as that.

[DiTBho]

To be frank, that doesn't make much sense. The C programming language is used BECAUSE of the standard. If you replace the standard with your own stuff, there is no reason to use C anymore.

Umm, sometimes I happen to use C because I don't have other high level languages for certain targets.

For example, I am writing a CAS software just right now for a proprietary terminal, and the only available SDK only provides a small C-89 compiler but no standard C libraries.

The same happened when I had to wrote an embedded firmware for an industrial embroidery machine whose control board is based on the A29k CPU, and yet again, I found nothing but a small SDK with a small C compiler and non standard C libraries.

[Fixpoint]

Umm, sometimes I happen to use C because I don't have other high level languages for certain targets.

Yes, I know. We all have that problem. And this will never change if developers of new libraries keep using C. If we want to advance, there is no other way than to make a step forward.

By the way, if a new library is implemented using a non-C language, you even could use it from C because natively compiled languages always provide means for efficient C bindings.

[Nominal Animal]

I am thinking of writing a new support library from scratch, replacing the standard C library, but exposing the same (Linux/POSIX) concepts, but without the historical baggage of standard C library functions

To be frank, that doesn't make much sense. The C programming language is used BECAUSE of the standard. If you replace the standard with your own stuff, there is no reason to use C anymore. Then you are free to use much better, more modern programming languages.

That's just your opinion.

The C standard provides two completely different environments, hosted and freestanding.  If I were to take your opinion at face value, the freestanding environment does not exist; there is no reason to ever use it.  Because it does, and is actively used for both OS (Linux and BSD kernels) and embedded uses, your opinion is faulty.

During the last decade, much better options than C have been developed

Better how?  That is the rub, isn't it.

Frankly, the CS articles I've read in the last decade or so, have concentrated more on constructing abstractions that help unskilled developers write code, and automatic detection and correction of the programming errors they create, than looking at robust, efficient, long-term maintainable code bases.  Hot air and gushing about favourites, without any true invention or progress.

I have seen zero proof that Rust, D, or Go, are actually technically superior to C.  All I've seen are opinions, sometimes based on chosen statistics.  You can always pick poor code in other languages, and write a much better version in your favourite language; but that is not proof of anything.  You need to actually compare the best implementations against each other, and that usually shows results programming language developers don't like to see, so they don't, either consciously or subconsciously.

The purpose of this library is to see how much better C could be, if we wanted it to be.

[DiTBho]

Yes, I know. We all have that problem. And this will never change if developers of new libraries keep using C. If we want to advance, there is no other way than to make a step forward.

100% agree with this. I thought the 2021 should be *THE* year to learn something new, for instead of investing money for fireworks, on  New Year's Eve I invested some money for a Rust course.

I can say "Rust", because I have a couple of customers that can provide a solid Rust SDK, so I can actually program something for a real target.

I have zero idea about what is better than what, I simply want to learn something new, with the hope that it will help my mind to grow in knowledge and wisdom.

That's it 

[Fixpoint]

That's just your opinion.

Surprise! But honestly, not quite. Fortunately, there are many people on this planet who know what I am talking about. But of course I get your point.

Because it does, and is actively used for both OS (Linux and BSD kernels) and embedded uses, your opinion is faulty.

Not so fast. Yes, there is software that doesn't use the standard library. But this software has a reason for doing that, so the question is why this software should use YOUR new library. The only point your library could make is that it is BETTER than the standard library. But what "better" means depends on the project.

Better how?  That is the rub, isn't it.

Well, not necessarily.

Frankly, the CS articles I've read in the last decade or so, have concentrated more on constructing abstractions that help unskilled developers write code, and automatic detection and correction of the programming errors they create, than looking at robust, efficient, long-term maintainable code bases.  Hot air and gushing about favourites, without any true invention or progress.

Without going into details: Yes, I agree that long-term maintainability is the big issue and that there hasn't been much innovation regarding that. Know what? That means that we are on the same page here. How, in God's name, are you going to tackle this problem with a C library that intends to replace the standard one?

I take it that you are fully aware of the challenges and the problems. So ... that would actually entail that you go the extra mile and don't use C. If you have good ideas, look into the future, not the past.

The purpose of this library is to see how much better C could be, if we wanted it to be.

You can make it as great as you please. This kind of experiment is not necessary, the result is clear.

Years ago I myself developed a C library that I *personally* much prefer to the standard one, it features a special form of hybrid memory management (basically a safe mixture of static and dynamic memory) and includes important data structures like strings, lists, and maps in a safe implementation (doesn't use this unsafe rubbish from the 70s). (But still, I don't want to use this library if I can avoid C.)

More recently, I also have developed a second C library (usable on small microcontrollers) that actually tackles the problem of long-term maintainability. Maybe I will release it when it is more mature, currently it is a bit basic.

However, I am doing nobody a favor with those libraries, and that holds me back. I know that actually a different programming language would be the real painkiller.

[PlainName]

The C standard provides two completely different environments, hosted and freestanding.

I think I've missed something. What is a hosted or freestanding C environment, or, rather, the difference?