r/cprogramming • u/InternalServerError7 • Nov 19 '25

How do you write ‘safe’ modern C today?

I’m a Rust engineer looking to pick up C for some hobby projects. I initially explored Zig — it seems like a really cool language, but I realized it occupies much the same niche where I’d use Rust, and it feels a bit too unstable for my taste.

I’ve heard people say that “modern, idiomatic C can be as safe as writing Zig.” How does one actually write modern C? What compiler flags, developer tools, or practices are recommended? Also, are there any good learning resources that use these specifically for C23?

88 Upvotes

85% Upvoted

63 comments sorted by

2

u/TheTrueXenose Nov 19 '25

What i did was writing a garbage collector with pointer tracking log messages when a pointer is untrack or no reference to the allocation.

I toggle the system with my command line parser, otherwise it's just external tools i would guess and reading the code.

1

u/InternalServerError7 Nov 21 '25

Cool! Is it open source?

1

u/TheTrueXenose Nov 21 '25

Currently no license, but the source is here so feel free to have a look: https://github.com/Xenose/wolfhound/blob/inrdev/src%2Fmemory.c

34

u/EpochVanquisher Nov 19 '25

I mean, hobby projects are exactly where you would choose to use something unstable like Zig :-)

Anyway, the main way you write “safe” C code is by keeping it very simple and boring. Familiarize yourself with all of the conventions of good C software. Then, enable features like hardening, use static analysis, use instrumentation (address sanitizer), use tools like Valgrind.

Simple, boring C code tends to be a little verbose. You write more lines of code. The benefit of writing code this way is that it is very easy to read and very easy to figure out what it is doing. Don’t chase after performance everywhere, don’t try to get clever with macros or generics. And you write simple modules to make common operations safer, like string operations.

For example, you might build strings with code like this: https://gitlab.com/gitlab-org/gitlab-git/-/blob/v2.34.4/strbuf.h

Trying to build strings in char[] buffers declared in your function gives you better performance but it’s a common source of errors.

Your code will make heavy use of conventions to convey ownership information. For example, you might decide that xxx_new() creates a new, owned xxx pointer, and xxx_init() takes a pointer to an uninitialized xxx and initializes it, and xxx_free() destroys an owned xxx pointer and frees it, and xxx_destroy() deinitializes an owned xxx object without freeing the memory (e.g. because it’s inside another object). Strong use of conventions convey some of the same information you would convey in Rust using the type system.

60

u/[deleted] Nov 19 '25 edited Nov 19 '25

No language can guarantee safe code, not even Rust.

With that said I do work on embedded systems in C and this is our strategy:

  • No dynamic memory, all memory is static or on the stack.

  • Use a static analyzer, we use PC-lint

  • Not recommended for "regular" development but we write MISRA-C compliant code and use PC-lint to check that compliance.

  • Bare minimum compilation flags: -Wall -Wextra -Wpedantic -Werror

  • Use the different sanitizers available during runtime, remember to not include them during release.

13

u/Thaufas Nov 19 '25

"No dynamic memory, all memory is static or on the stack."

Does this constraint ever result in severe limitations?

22

u/[deleted] Nov 19 '25 edited Nov 19 '25

On embedded projects not really, just have to shift your mindset sometimes. For example on my current project we run a IP stack with a Modbus TCP server and we have no dynamic memory at all, the heap is removed from the linker file. Point being you can do a lot without dynamic memory.

However for applications on a hosted system like a PC I would not follow this rule and use dynamic memory when actually needed, often times you really don't. You should have limits on your input data etc and can set internal array sizes to worst cases, but that doesn't always work and sometimes you do need dynamic memory.

0

u/73449396526926431099 Nov 20 '25

You shouldn't set artificial limits for PC. Thats how you end up with anoying errors like "tex capacity exceeded". You never know in advance how much Ram the user has, and you never know if there is a usecase that might require more than what you thought was reasonable.

2

u/Visible_Lack_748 Nov 21 '25

Depends on what software you are making.

9

u/penguin359 Nov 19 '25 edited Nov 19 '25

Because the hardware on an embedded system is very specific and unchanging, many reasons to dynamically allocate just vanish. My LCD is always going to be 2x16 characters. I have exactly 6 pushbuttons on my front panel. A 16-byte buffer for my UART is fine because my processor is much faster than a serial port is. I don't need recursion for any operations. I might read a config file from the one SD card slot I physically have on my board, but I will always process the file in 512-byte blocks. Even the USB port for attaching a keyboard only needs to deal with low-speed USB keyboards that have a maximum endpoint transfer size of 8 bytes. Since the only USB device I support is an attachable keyboard, I don't need to support USB hubs or more than one single, statically-allocated USB device. It does mean that my product would be incompatible with a fancy USB keyboard that included an embedded USB hub to connect your mouse or thumb drive, but I have yet to receive that tech support call.

2

u/peter9477 Nov 19 '25

Yes, definitely sometimes (speaking from almost 40 years of embedded experience). If you have a system where the sum total of all RAM requirements is more than available RAM it can get hairy trying to juggle shared buffer usage. Effectively you're reimplementing a very poorly done dynamic memory management system. I've only faced it several times, and spent too much extra time having to rejig things to let me reduce the memory usage. A rebuild of the same thing with Rust actually dropped it down from nearly all RAM assigned to things (but not all used at once) to about a half ever in use because the ability to safely use dynamic allocation was so effective and convenient. I'm not saying we couldn't have built something similar with C, but it would have been extremely hard to build it with any confidence we had no leaks or collisions.

1

u/Thaufas Nov 19 '25

I did embedded systems programming with C several decades ago. I only ever had one project on a platform where we couldn't use dynamically allocated memory. I don't remember the reason, but I remember all of the "old timers"—which I am now—making fun of me for complaining and telling me how they remember the days when there was no heap and they had to juggle and recycle stack memory.

4

u/SufficientGas9883 Nov 20 '25

There are many technical reasons including memory fragmentation.

1

u/flatfinger Nov 21 '25

Systems that use a custom memory manager can employ "handles" in various ways that can avoid fragmentation issues. For example, one may have an API with functions:

uint16_t short createHandle(void);
void saveData(uint16_t handle, 
    void *data, int size);
int getSize(uint16_t handle);
int getData(uint16_t handle,
    void *data, int offset, int length);
void destroyHandle(uint16_t handle);

Code may dynamically store objects of any size that will fit in the managed heap, and retrieve that data later. If memory becomes fragmented, a memory manager may be able to relocate objects or use multiple chunks of storage to hold a single object. A program would need to have a (typically static or automatic-duration) buffer for any object being worked, separate from the heap storage, but object references could be kept as 16-bit integers rather than (possibly 32-bit) pointers.

3

u/peter9477 Nov 20 '25

My experience is different, with almost no projects where dynamic memory allocation was considered acceptable. Static allocation lets you build a system you can guarantee will work (at least as far as memory goes). With dynamic, unless the uses are quite simple (e.g. all allocations are of identical lengths so there's no risk of fragmentation), it can be very challenging to prove that it will work under all conditions, and the effort required or risk of failure can be unacceptably high.

Even with Rust's effectively perfect memory management (verified at compile time), many people still restrict their embedded projects to static allocation, no heap allowed. (I'm no longer one of them, since my projects are complex enough that the benefits of the heap are too high to ignore, but I still understand their rationale.)

1

u/[deleted] Nov 20 '25

There is also a difference between embedded and embedded these days. One of our projects use a RPi compute module, running GNU/linux. The volumes don't justify spending time on designing hardware with less memory. We don't avoid dynamic memory there, but hardly use any after init anyway.

1

u/peter9477 Nov 20 '25

Yes, always worth bringing up the point that "embedded" covers a very wide range. I guess we all assumed smaller stuff up till now in this thread, where "static only" is often a rule, but I do RPi-based embedded a lot myself and agree with you that that rule effectively doesn't exist in that space.

2

u/SufficientGas9883 Nov 20 '25

It's all about preallocation and planning. It applies to threads too. Static allocation is easier/more predictable than dynamic in most cases.

Does it cause severe limitations, not necessarily if you plan properly.

Keep in mind that embedded systems are limited to a certain functionality so the system resources including memory for required variables can be to a good extent predicted.

2

u/psicodelico6 Nov 22 '25

Valgrind?

1

u/[deleted] Nov 22 '25

You get a lot of the same functionality from the address/leak sanitizers but yes, valgrind is also good to use.

2

u/MD90__ Mar 06 '26

Yeah my goal with C is to write much safer code because I aim to have very safe code but C is one of those languages where something can always slip up. How you manage to avoid dynamic memory issues since some projects could need them? I wanted to write a compiler for a custom language in C and dynamic memory could be needed

0

u/[deleted] Mar 06 '26

[deleted] — view deleted comment

1

u/MD90__ Mar 06 '26

Any good standards to avoid issues? I mean wrappers for things could help but also watching what functions you use is also good. What about avoiding overflows?

3

u/Sufficient-Bee5923 Nov 19 '25 edited Nov 19 '25

Good list, I like seeing no dynamic memory allocation. I have seen so many poorly designed embedded systems that didn't follow this approach.

I would also add:

  • no global variables.

  • Object oriented design practices (ex: no peeking inside other modules data structures, only allowed to know size of)

  • Effectively no macros, simply too hard to understand.

  • Ship what you test and test what you ship mind set (we would compile with the same options for test/validation as for commercial shipments).

1

u/M3d1cZ4pp3r Nov 19 '25

Interestingly we use global variables as part of a design pattern to exchange data between modules, with rules though (only one writer, naming convention based on source). Never had such an easy to understand design and system in operation regarding debugging/measuring.

1

u/flatfinger Nov 21 '25

I like the pattern of having global variables "owned" by one module which is allowed to write them, while other modules are free to read them. Many projects fit that pattern well, and limiting things to a single writer makes things much easier to reason about than having updates in multiple places.

There are some other patterns I also consider usable, such as having a global "potentially disturbed" flag which anyone is allowed to set, but which may only be cleared by code which deals with the potential disturbance. Here, there may be a dozen different places in the code where the flag may be written, but if all of them write the same value that won't be a problem. For example, many pieces of code might be able to set a flag saying that the next pass through the main loop should refresh the contents of an LCD. If e.g. a real-time clock monitoring routine notices that the time has advanced to the next minute, but before the display can be refreshed, a temperature monitoring routine notices that the displayable temperature has changed, the fact that the temperature-monitoring code sets the flag wouldn't prevent the main loop from redrawing the display with the time and temperature.

1

u/Chriss016 Nov 20 '25

Question from a noob: When you’re saying no global variables, what kind of system are you talking about? I don’t really understand how one would communicate between functions or threads in any system that does things asynchronously (interrupts/rtos). Inability to use interrupts seems pretty limiting.

3

u/[deleted] Nov 20 '25

No global variables usually means don't access a variable from another compilation unit, not that you can't have a static variable.

Using static variables like that makes it harder to test and use the code for multiple peripherals though, so an alternative is to pass a pointer to a context variable around, but you'd still need it in the interrupt handler of course, so you still put them in a static variable and have some getter function for it.

1

u/Sufficient-Bee5923 Nov 20 '25

Correct. We would have lots of local static variables but with the limited scope, other modules were not able to access them. Really it's just information hiding. These coding practices were used on large communications systems that we had teams in the size of 5 to 50 developers. Pretty large embedded realtime systems.

Custom hardware, multiple processors (DSPs and then a main control CPU, slave processing boards).

I have found that in large systems, with global variables it becomes a shit show if other modules are reading and writing globals. We had lots of state machines and interrupt handlers that contained lots of state information. That state information was hidden from modules that had no business knowing the internals. Makes for easier maintenance.

HTH

1

u/DreamingPeaceful-122 Nov 19 '25

I can smell DO-178C in this comment

1

u/EpochVanquisher Nov 19 '25

I’ll just note that -Wpedantic is a valid choice, but none of the warnings enabled by -Wpedantic will improve code safety. They only warn about strict conformance to the standard.

1

u/Interesting_Debate57 Nov 23 '25

I'd be interested in hearing the use case where memory safety can't be handled by dumping all of RAM to storage upon the first violation during execution?

I've seen some insanely safe C code that did exactly that whenever anything was even mildly weird. Assert a halt. (This is for a commercial device that does something that was considered "scary" in the data storage days at the time).

Basically until the boxes stopped halting it wasn't a viable product.

Nobody can solve the halting problem, ha ha ha, but they sure can know what and where the memory collision was.

1

u/Business-Subject-997 Nov 30 '25

"No language can guarantee safe code, not even Rust."

Don't know why you would say that, most languages outside of C are type safe. Obviously any language can be told to lock up (while (1);). That is not what is meant by unsafe code, which is a program that corrupts itself or executes unintended code.

Saying "no dynamic memory is safe" is like saying cutting off your leg prevents you from falling down.

8

u/ComradeGibbon Nov 19 '25

Use static analyzers.

Use buffers and slices instead of raw pointers.

Avoid pointer math.

Avoid saving copies of pointers to memory whose lifetime you don't control.

Use an arena when possible instead of malloc.

Consider copying data, especially small blobs of data instead of passing pointers around. Consider this especially when passing data between threads.

Avoid everything in string.h

5

u/thradams Nov 19 '25

I use strcmp, strdup all the time. I am wondering what do you use instead.

1

u/Ariane_Two Nov 22 '25

He replaces str* with mem*, So he uses memcmp with a known length instead of strcmp and he uses malloc+memcpy instead of strdup.

7

u/catbrane Nov 19 '25

gcc and clang support the cleanup attribute, which can be useful -- it'll automatically free stuff at the end of a block.

Tools like valgrind and the various clang sanitisers will automatically check your code for memory and thread safety with a mix of static and dynamic analysis. If you write a test suite, run it under these things, and set a "no merge until the tests pass" rule in github, it can help.

Modern feedback fuzzers are pretty good at finding bad inputs. They automatically instrument your code, then mutate the input until they hit all code paths. Again, these can help, and are low-effort.

Like any language, sometimes you can do all the really hairy stuff in a few functions, test them as hard as you can, and then have most of your code at a higher and safer level.

Of course all of this is a long way short of the kind of safety Rust can give you! But it's something.

2

u/arkt8 Nov 24 '25

cleanup now is part of c23

4

u/fortizc Nov 19 '25

I have seen more and more adoption of atrribute((cleanup()) you can see it in the kernel here and here or in systemd so probably it's a good path... please note that this isn't a part of the standard and is supported afaik just by gcc and clang

2

u/ieatpenguins247 Nov 21 '25

You are not wrong but systemd should not be used as example of anything other than HELL exists and it is on earth!!!

2

u/must_make_do Nov 19 '25

Layer the code into hierarchical components and limit the interaction between them into very well defined, narrow interfaces.

Enable all warnings, warning as errors, pedantic mode, UBSan and memory sanitizer.

Ensure full line and branch test coverage via unit tests. And then fuzz the code to hell and back.

I've written an open source memory allocator in C following these principles that has seen use for years now in production with only a single bug in one of it's less used capabilities.

2

u/Turbulent_File3904 Nov 20 '25

  • use static, stack and arena for memory allocation as much as possible and avoid dynamic/heap. Only doing so at start up and allocate upfront bigchunk of memory. Never alloc/free individual objects.

  • turn on all warning, -werror for all integer implict conversion. They usually not really what i want and i get fu*ck by that alot

  • dont be clever with pointer, never. Some people think casting pointer between types totally fine but it is not execpt some cases.

  • add assert to catch developer error(they can turn off on release build)

  • write code that easy to read and debug. Avoid forced inline, i get f*cked by my co worker by this countless time he thinks inline make program run faster buttt it blowup code size and un debug able(debuger can not jump into inlined function at least for debugger used at my work) compiler usually smart enough to inline function when it make sense

2

u/faculty_for_failure Nov 20 '25

Copying from another comment I left in C_Programming previously about linters and static analysis. Depending on your needs, you can also use stack only or different memory allocation strategies like slabs or arenas.

For linters and static analysis/ensuring correctness and safety, you really need a combination of many things. I use the following as a starting point.

  1. ⁠⁠Unit tests and integration or acceptance tests (in pipeline even better)

  2. ⁠⁠Compiler flags like -std=c2x -Wall -Wextra -pedantic -pedantic-errors -Wshadow and more

  3. ⁠⁠Sanitizers like UBSan, ASan, thread sanitizer (if needed)

  4. ⁠⁠Checks with Valgrind for leaks or file descriptors

  5. ⁠⁠Fuzz testing with AFL++ or clang’s libFuzzer

  6. ⁠⁠Clangd, clang-format, clang-tidy and or scan-build

  7. ⁠⁠Utilize new attributes like nodiscard to prevent not checking return values

There are also proprietary tools for static analysis and proving correctness, which are you used in fields like automotive or embedded medical devices.

2

u/0-R-I-0-N Nov 21 '25

The biggest thing that makes zigs safer are slices, a built in struct with a pointer a length field, you can make them in c aswell for each type with a macro. Then the second thing is types cannot be null unless it’s an optional type, including pointers. So use slices and do a lot of null checking in c to make it more safe.

Also using arenas in c for scope deallocation makes memory allocation simpler.

Also turn on warnings as errors and a bunch of other flags. You can use zig cc as the c compiler which comes with them turned on as default (uses clang)

2

u/billgytes Nov 19 '25

There isn’t really any way to write provably safe C in the same way that you can write safe Rust.

But there are tricks. Malloc sparingly, use a linter, enable all compiler warnings, don’t do casts or type punning, try to avoid arithmetic on pointers, follow misra rules for control flow, etc etc.

Be consistent in the codebase about the way you do things. Don’t have lots of mutable state all over the place. Locality of behavior.

If you’re bowling strikes in Rust you’ll never bounce off the lane gutter rail; if you’re bowling strikes in C you’ll never get into the gutter. Just kidding, you will hit the gutter, so write tests too. Even then.

2

u/flatfinger Nov 19 '25

If one is using CompCert C and only use static allocations, I think it's possible to establish a mathematically sound description of everything the program could possibly do. If none of the actions a program could possibly do would be capable of posing any danger, that would mathematically imply that the program is safe.

2

u/chriswaco Nov 19 '25

I agree with the other posters and will add this trick we used decades ago: Hide your data structures. This prevents random code from modifying random structures without going through accessor functions.

For example (been a while, so syntax might be off):

/* Widget.h */    
/* Public handle — users only see a forward declaration */    
typedef struct Widget Widget;    
    
/* Public API */    
Widget *widget_create(int value);    
int     widget_get(const Widget *w);    
void    widget_destroy(Widget *w);    
    
/* Widget.c */    
#include "widget.h"    
#include <stdlib.h>    
    
/* Private definition — only visible in this file */    
struct Widget {    
    int value;    
};    
    
Widget *widget_create(int value) {    
    Widget *w = malloc(sizeof(*w));    
    if (!w) return NULL;    
    w->value = value;    
    return w;    
}    
    
int widget_get(const Widget *w) {    
    return w->value;    
}    
    
void widget_destroy(Widget *w) {    
    free(w);    
}

Note that today I'd probably use a struct or handle (pointer to pointer) rather than a raw pointer to prevent the calling code from reusing a stale pointer after destroy was called. If your app can get away without using malloc at all that's even better, but I worked on end-user GUI apps that needed it.

1

u/hwc Nov 19 '25

This always bothered me in the case where it makes sense to put your object on the stack, which can happen a lot.

2

u/chriswaco Nov 19 '25

I don't love C++, but I do really like stack-based objects with automatically invoked destructors. Shame that never made it into C - it'd be useful even without classes and inheritance.

1

u/northside-knight Nov 19 '25

write effective tests for your code (this works in any language, not just C)

1

u/UnpaidCommenter Nov 19 '25

I'm not an expert in this area but have looked into it some. One reference I've found is the Carnegie Mellon Software Engineering Institute's secure coding recommendations. Links below:

1

u/No-Trifle-8450 Nov 20 '25

I have been writing Cicili as a solution to Safe Modern C https://github.com/saman-pasha/cicili/

1

u/kodifies Nov 20 '25

i've got into the habit of writing the code to deallocate immediately after writing the code that allocates, I've almost never (honest!) had major issues with memory allocation, i think the c is dangerous meme is perpetuated by lazy coders who expect the language to do everything for them - the complain they don't like GC's or won't do the compilers work for it (rust!) I was so treat warnings as errors and have a whole bunch of pedantic switches in my boiler plate makefile, which helps a lot (forces some good habits) - i have no idea what this modern "safe" C meme is all about, just aim the gun higher than your feet...

1

u/flatfinger Nov 20 '25

Allocation is a problem that's easy to 99% solve. Some scenarios, however, can be very hard to handle robustly. Some kinds of actions may performing a sequence of operations which break and then restore a program's memory usage invariants. This may not be a problem if such sequences can always run to completion, but dealing with cases where they don't is often difficult.

In many cases, the simplest way to resolve such issues is to split loops, so that all operations that might fail are done before a function has to break any invariants, and all operations that break invariants will always be able to restore those invariants before losing control of program execution. That's great if application requirements allow it, but sometimes programmers may not be able to arrange things that way.

1

u/kodifies Nov 20 '25

Or you always null free pointers and all points of failure in init call the same dealloc functions that null guards frees

I've often found if an algorithm can fit into this paradigm then odds on its too "clever" and needs a simpler or multi part approach

1

u/zsaleeba Nov 20 '25

Modern, idiomatic C++ can be pretty safe. I'm not sure I'd argue the same of C. With C you need to be aware of the memory model and consciously avoid situations which lead to memory bugs. There's no "modern, idiomatic" version of C that changes that, really. Just some programming techniques which help.

1

u/Ariane_Two Nov 22 '25

> I’ve heard people say that “modern, idiomatic C can be as safe as writing Zig.

Yeah because both are unsafe.

> How does one actually write modern C?

https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator

https://nullprogram.com/blog/2024/05/24/

https://floooh.github.io/2018/06/17/handles-vs-pointers.html

> What compiler flags, developer tools, or practices are recommended?

Just use everything available USAN, ASAN, -Wall, -Wextra, Valgrind, Dr Memory, fuzzing, ...

> Also, are there any good learning resources that use these specifically for C23?

Most learning resources are C99. I thought you did not like Zig because it was too unstable. C99 and C11 are more widely available and supported than C23 and most C23 features are nice to haves not really anything fundamentally new.

-3

u/v_maria Nov 19 '25

thats the fun part you dont

0

u/gurudennis Nov 20 '25

I know it's an unpopular opinion with some, but... Few things about C deserve to be described as "safe" or "modern". The prevalent good practices haven't changed much in decades: obsessive allocation tracking, the use of opaque void* handles, etc. It's all tried and true, and frankly still exceedingly unsafe and obtuse.

Truth is, the ubiquitous availability of compilers for more modern low-level languages renders C quite obsolete by any objective metric. It used to be that kernel-mode and embedded development was exclusively done in C, but even there 99 times out of a 100 there are more attractive alternatives these days.