> Even such a simple use case is fraught with major problems:
>
> 1. who allocates needed memory?
>
> 2. who free's it?
That's also a major feature. It allows people to write systems that are resilient in the face of tight memory limitations. It's not cool when a language forces string operations to allocate & duplicate memory willy-nilly.
> 3. can the compiler constant fold cat("hello","world") ? Does the result wind up allocating memory anyway?
I fail to see how that's a major problem. Why are you concatenating string literals? How common is that?
> 4. what about the lack of function overloading to handle the permutations?
I consider lack of overloading to be a feature. Overloading is one of the things that are way too easily abused, and it makes code auditing harder than it needs to be. Please just type out the different function names so I can see exactly what is going to be called when I read the code. Or use the sprintf family of variadic functions.
It's the opposite. I've seen lots of code written in C that pretends to be out of memory safe. I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised.
With a GC and exceptions you can theoretically be quite resistant to OOM conditions, not that anyone really cares.
> I've never once seen such a program that actually is out of memory safe. Invariably the codepaths triggered by malloc returning null are never exercised.
sqlite takes care to correctly deal with out of memory conditions. It has explicit tests for that code too. See section 3.1, Out-Of-Memory Testing, of [1].
Now I found my first program that actually tests it properly :)
I knew you had to systematically drive the code through every OOM codepath to even have a shot at doing that in an unmanaged language. Sadly a lot of C code is written by people who think:
if ((ptr = malloc(sizeof(struct foo))) == null)
return -1;
One of the things with tight memory systems is that you don't use malloc to begin with, if you can avoid it. C gives you the option.
When you're concatenating strings, you already have storage for those strings. Maybe you can re-use that storage. Maybe you have a static buffer. Maybe you have a fixed size buffer on the stack and the stack use is bounded.
A language that forces you into making redundant duplicates onto the heap is terrible in these situations.
And yes there are programs that try to deal with failing mallocs. Again, C gives you the option.
Very, very few C programs can handle running out of disk space. This includes the operating system(s). Get close to filling up the disk, and try various things.
Just recently, I was having a lot of trouble with Windows Update hanging. I finally noticed that free disk space was low. Freed up more space, and WU started working again.
For fun, try:
#include <stdio.h>
int main() { printf("hello world\n"); return 0; }
and redirect stdout to a file on a device that is full. Amazingly, it succeeds!
That's also a major feature. It allows people to write systems that are resilient in the face of tight memory limitations. It's not cool when a language forces string operations to allocate & duplicate memory willy-nilly.
> 3. can the compiler constant fold cat("hello","world") ? Does the result wind up allocating memory anyway?
I fail to see how that's a major problem. Why are you concatenating string literals? How common is that?
> 4. what about the lack of function overloading to handle the permutations?
I consider lack of overloading to be a feature. Overloading is one of the things that are way too easily abused, and it makes code auditing harder than it needs to be. Please just type out the different function names so I can see exactly what is going to be called when I read the code. Or use the sprintf family of variadic functions.