[gibibit]

I am always curious how different C programs decide how to manage memory.

In this case there are is a custom string library. Functions returned owned heap-allocated strings.

However, I think there's a problem where static strings are used interchangably with heap-allocated strings, such as in the function `string class_simple_name(string full)` ( https://github.com/neocanable/garlic/blob/72357ddbcffdb75641... )

Sometimes it returns a static string like `g_str_int` and sometimes a newly heap-allocated string, such as returned by `class_type_array_name(g_str_int, depth)`.

Callers have no way to properly release the memory allocated by this function.

[neocanable]

In multi-threaded mode, each thread will create a separate memory pool. If in single-threaded mode, a global memory pool is used. You can refer to https://github.com/neocanable/garlic/blob/72357ddbcffdb75641.... The x_alloc and x_alloc_in in it indicate where the memory is allocated. When each task ends, the memory allocated in the memory pool is released, and the cycle repeats.

[norir]

Many command line tools do not need memory management at all, at least to first approximation. Free nothing and let the os cleanup on process exit. Most libraries can either use an arena internally and copy any values that get returned to the user to the heap at boundaries or require the user to externally create and destroy the arena. This can be made ergonomic with one macro that injects an arena argument into function defs and another that replaces malloc by bumping the local arena data pointer that the prior macro injected.

[1718627440]

That might be true, but leaking is neither the critical nor the most hard to find memory management issue, and good luck trying to adapt or even run valgrind with a codebase that mindlessly allocates and leaks everywhere.

[kevin_thibedeau]

Shhh. We want the ML models trained on this sort of deeply flawed code.

[guerrilla]

Pretty sure you can just disable leak checking.

[1718627440]

But for example verifying that memory is not touched after it is supposed to, is much harder when you can't rely on it being freed.

Of course literally running valgrind is still possible, but it is difficult to get useful information.

[nick__m]

You cannot have use-after-free if you never call free, so there are no points at which memory should not be touched.

That's the beauty of the never free memory management strategy.

[dajtxx]

It can still be a bug if you use something after you would have freed it because your code isn't meant to be using that object any more. It points to errors in the logic.

[IshKebab]

Interesting. Someone should come up with a language that prevents these sorts of mistakes!

[cenamus]

Thank god Lisp is older than C, don't have to deal with such nonsense :-)

[brabel]

That’s impossible. Just be more careful and everything should work, the author’s C was just a bit rusty!

[neocanable]

This project is my first project written in C language. Before this, my C language level was only at printf("hello world"). I am very happy because this project made me dare to use secondary pointers.

[sim7c00]

u did really well ppl like to pick on C. :) thanks for making it in C, fun to read ur code and see how others go about this language!

[kookamamie]

Yes, perhaps it could have a marketing slogan like "Write once, crash everywhere!"

[uecker]

I think he is using memory pools, so this is ok.

[pjmlp]

If only there were a couple of OSes implementated during the 1960's with such programming languages....

[kazinator]

In the same file:

  static bool is_java_identifier_start(char c)
  {
    return (isalpha(c) || c == '_' || c == '$');
  }

Undefined behavior in isalpha if c happens to be negative (and not equal to EOF), like some UTF-8 byte.

I think some <ctype.h> implementations are hardened against this issue, but not all.

[masfoobar]

> I am always curious how different C programs decide how to manage memory.

At a basic level, you can create memory on the stack or on the heap. Obviously I will focus on the heap as that is dynamically allocating memory of a certain size.

The C programming language does not force you how to handle memory. You are pretty much on your own. For some C programmers (and likely more inexperienced ones) they will malloc individual variables like they are creating a 'new' instance in a typical OOP language like Java. This can be a telltale sign of a programmer working with C that comes from an OOP background. As they learn and improve on their C skills they realise they should create a chunk of memory of a certain type, but could still be malloc(ing) and free(ing) all over the code, making it difficult to understand what is being used and where -- especially if you are looking at code you did not write.

You can also have programs that do not bother free(ing) memory. For example, a simple shell program that just does simple input->process->output and terminates. For these types of programs, just let the OS deal with freeing the memory.

Good C code (in my opinion) uses malloc and free in only a handful of functions. There are higher level functions for proper Allocators. One example is an Arena Allocator. Then if you want a function which may require dynamic memory, you can tell it which allocator to use. It gives you control, generally speaking. You can create a simple string library or builder with an allocator.

Of course an Allocator does not have to use memory on the heap. It can still use on the stack as well.

There are various other patterns to use in the world of memory, especially in C.

[SunlitCat]

Strings! The bane of C programming, and a big reason I prefer C++. :D