I was talking about application level code.
Ah, okay. I thought/assumed this was about code running on a microcontroller or similar embedded and constrained devices.
If you told me that you re-wrote malloc (which is part of the standard C library) for a project (that runs on an modern OS) then I would tell you that this is stupid.
I agree, if we are talking about writing our own
malloc()/realloc()/free() functions.
But, I am not: I am talking about replacing such things with completely new functions.
I only showed the
xxxtoa() implementations as a concession, to discuss the details of numeric-to-string conversion only; I do not use that interface in code I write myself.
When I talk about replacing the standard C library, I mean with something other than the interfaces defined for the standard C library in the hosted environment. If I were to talk about writing my own implementation of the hosted environment standard C library, I'd use 'reimplement the standard C library'.
Thus, whenever we're talking about replacing the standard C library, I am specifically talking about something with completely different interfaces and functions, with function names different than those in the standard C library; and not just reimplementing a superset or subset of the standard C library interfaces.
Thus, it really is an error to think of the C standard library as an irremovable part of the C language.
I agree with that, although I'm not sure why you would tell me, because I said "I never said it's part of the language." above.
Me fail English then –– I do pretty often. You did use the qualifier 'de facto',
"in fact or in practice; in actual use or existence, regardless of official or legal status", and I disagree even with that qualifier, because a lot of the code that drives C language development, uses the freestanding environment completely without the standard library; and because a large part of the "stagnation of C" is actually stagnation of the standard C library!
I've mentioned it before, but the lack of
strdup(),
strndup(),
getline(),
getdelim(),
asprintf(),
vasprintf() etc. in the standard C library is utterly silly. They are widely used, and definitely help write more robust real-world systems or application-level code. (Some of them are in POSIX, some are GNU only, some have BSD equivalents.)
To me, this is
proof of the stagnation of the standard library part of the C language.
My argument is that instead of replacing C with something completely new, we should look into replacing the standard C library first, with something better.
The design work for systems or application-level programming is huge, but for the microcontroller and embedded world, running on plain hardware without an OS, the set of library-provided features is much smaller, and quite feasible to tackle.
Doing that one will for sure discover some core C language properties that ought to be modified; but that I consider the
next step, to be discussed when one has practical and useful proof to show how to do it better (in the form of a replacement for the C standard library, with completely different functions).
(I admit I have done quite a bit of experimentation and research into replacing the standard C library for Linux systems programming, but that stems from the fact that the Linux kernel provides interfaces that POSIX compatibility fights against; for example, per-thread credentials (user, group).)