I picked out these I noticed after digging some code at work:

1. System Calls. I don't even think about them and until recently, I wouldn't have had to.

2. Memory layout (If you asked where in memory a certain part of the code was or how it was laid out, I couldn't tell)

3. Thread management (This is what prompted this post)

What else comes to mind for you?

And try as I might to avoid them, I am struggling to find resources that list out all the file control functions that use file descriptors instead of file pointers, and I was wondering if someone could point me toward a resource that can do something at least somewhat similar to listing out the libc functions that take file descriptors. I of course know close(), write(), read(), the basics, but i am looking for alternatives for other abstractions that annoy me with their use of file pointers, like fgets and fputs.

So I'm working on an interpreter for ane extended version of brainfuck and wanted to implement bitwise operators. They give results practically unpredictably. As noted in the title the operators are applied to unsigned chars.

Here's the code

case AND :  
          switch (lex_code[codep + 1].token)
          {
           case NUMBER : array[memp] &= lex_code[codep + 1].value.numb; break;
           case GOTO_VALUE : array[memp] &= popValue(); break;
           case VAR_NAME : array[memp] &= array[get_hash(var_table,next_lex.value.name)]; break;      
           default: array[memp] &= array[memp + 1]; break;
           }
                    

The same code applies to other operations

i dont understand what happens here:

IF int b is a 2d array then what is:

b + 1

*(b + 1)

&b[0] and b[0] and &b[0][0]

&b[1] and b[1] and &b[1][0]

what are the differences between each and what is the byte value of each.

Ok, let's get this out of the way first - this leans heavily on AI to create the compiler. For a single developer, it was do it that way, or just don't do it. Here's what 6 months or so of co-development gets you:

• A fully independent compiler, open source and available at https://github.com/ThrudTheBarbarian/xc

• Supports Windows, Linux, and Mac, compiles for those and WASM, iOS, Android amongst others. Has a cross-platform UI library to aid single-source development

• Natively supports both the CPU (threaded) and any number of GPUs on the system (can even be different architectures). No GPU SDKs needed.

• If you run 'xcd' on a remote machine, it can reach across the network and parallise your code to use remote GPUs as wel, if it makes sense to do so.

• No need to manage data across CPU/GPU interface

• No need to identify which parts of the program should be parallelised, though you can if you want

• It's actually its own language but it will accept standard C files and do all the same parallelising on those C files. It uses clang to convert "C" source to first-stage LLVM IR, converts the IR to our IR, and everything after that is as if you'd coded in xc

• It reads DWARF symbols (types, functions, ...) from C libraries, so it natively binds to them without any "foreign function interface" malarky

• It figures out what hardware it can run on at run-time, not compile-time, so it will use the best hardware available for that person at that time

• It's fast, see the C benchmarks (including mandelbrot.c below on a variety of platforms for comparison)

To give an idea, a full and complete program for a mandelbrot, mandelbrot.c, might look like:

    #include <stdio.h>
    #include "bench_time.h"
    #define W (2048 * BENCH_SIDE)
    #define SIZE (W * W)
    int main(void)
        {
        unsigned total = 0;
        long long best = 0, first = 0;
        for (unsigned rep = 0; rep < 8; rep++) {
            total = 0;
            long long t0 = bench_now_us();
            for (unsigned i = bench_zero(); i < SIZE; i++) {
                float cx = (float)(i % W) * (3.0f / (float)W) - 2.0f;
                float cy = (float)(i / W) * (3.0f / (float)W) - 1.5f;
                float x = 0.0f, y = 0.0f;
                unsigned k = 0;
                while (k < 256 && x * x + y * y < 4.0f) {
                    float xt = x * x - y * y + cx;
                    y = 2.0f * x * y + cy;
                    x = xt;
                    k = k + 1;
                    }
                total = total + k;
                }
            bench_keep(total);
            long long t1 = bench_now_us();
            if (rep == 0)
                first = t1 - t0;
            if (rep == 0 || t1 - t0 < best)
                best = t1 - t0;
            }
        printf("%u %lld %lld\n", (total + 500000) / 1000000, best, first);
        return 0;
    }

bench_time.h is just a platform-independent way of getting a micro-seconds count from the start to the end. Note the complete absence of anything to do with GPUs at all, or any "#pragma parallel for", or any other annotations - this is just C code.

Compile it with:

prompt% xcc -o mandel mandelbrot.c

And then if you want to see how work was divided after running with --xc-par-trace, use the par-trace webpage tool to analyse it, getting something like the image at https://0x0000ff.co.uk/img/xc/par-trace.png

Because xc measures the performance at run-time (and then persists so it doesn't need to measure unless things change significantly), it can determine whether it's worth moving the code to the GPU (if it's compute-bound) or keeping it on the CPU (because it's data-bound). There's more information on how it manages the parallelism on the website.

Because speed is a focus, xc will still use the GPU even when rounding might produce slightly different answers on floats (for operations which aren't associative). This can be tuned (again, at runtime, or in fact compile-time) because parallelised blocks are named, and preferences can be set for the destination (CPU/GPU) on a per-block basis.

xc has only just hit version 1, and there's a long way to go yet, but it's already pretty good at auto-parallelising standard code onto GPU(s). Happy to answer any questions :) And if you find cases where you think "that should have done X and it did Y", I'm interested in bug-reports, either here or (preferably, since it's more integrated) on the Issues page on the github repo.

In this video we learn to extract layers from the Tiled map JSON file and smartly store them as pointer arrays using calloc to manage the memory better.

CODE: https://github.com/steelx/sdl3-tutorial

This is part of my Handmade JRPG series we are using C Programming and SDL3. NO AI USED.

(ep 05 planned over Weekend) Next video is we connect all things to finally render our Tiled map.

I recently finished a project I've been working on: primitive-rsa, a from-scratch implementation of RSA in C17.

I initially started this project after the original RSA paper.
I was quite amazed since I only recently started learning about cryptography how much simple RSA encryption actually is (atleast on paper).

So I thought maybe I should try implementing it.

But ended up thinking I should do it from scratch means implementing in C (It was my first time building a project in C) and not relying on libraries (no GMP).

So I tasked myself with implementing an arbritary precision library or simply bigint library in C which atleast provides all the necessary arithmatic operations required by RSA.

Than I finally realised why people say it's pain to handle memory.

Literaly whenever I call a function like basic add(a,b) i need to check return result for allocation failure and if allocation fails I needed to free all the holding resource carefully.

It may sound simple but when implementing an complex algorithm like FFT where we have so many operations in single function.
Each functions call becomes a pain to write.

Although it was quite headache to always think about allocation failures, memory leaks, or can this be optimized with SIMD or will this integer overflow. Will it fit in 64 bit etc.

I learnt a lot, different cleanup patterns in C. Different algorithms like FFT / NTT, Chinese remainder theorem is used. Finite spaces like how montgomery reduction is used to avoid division operation and much more.

I ended up implementing several components myself:

• A custom arbitrary-precision integer library.

• Schoolbook and FFT/NTT multiplication.

• Knuth's Algorithm D for division.

• Montgomery reduction for modular exponentiation.

• Miller–Rabin primality testing.

• Extended Euclidean Algorithm.

• RSA key generation, encryption and decryption.

I also tried to explore implementation efficiency rather than relying on existing BigInt or cryptography libraries.

This was primarily a learning project, and it's not intended for production use.

It was a great exercise in C, number theory, algorithms and understanding how cryptographic systems work under the hood.

I'd love to hear feedback, particularly on the BigInt implementation, algorithm choices, and project architecture. I'm still learning, so constructive criticism is very welcome!

AI usage: mostly for docs and demonstration code (in main.c) and for snippets like logging and some testing codes.

GitHub: https://github.com/akramdevstuffs/primitive-rsa

I worked in C for years . i have used arenas a lot in the past. Today i have to modify an old c program , nothing difficult but i found something that made me think. Who developed the code ( very well written and documented ) used an arena for allocating variable.

What 's seems to me strange is that he did not used an heap memory area ( malloc ) but it used a char [] buffer and used it for its arena . At that point he could obviously allocate directly variable in stack instead he grabs all its variable from that buffer . Why a choice like that ? i thought for the CPU cache L1/L2 and so on ( all the "arena" will likely be in cache of the cpu ) but it is only an ipotesys and i was asking to you , in your opinion , the reason of a such choice .
Just curiosity .

Thanks

PP

Hey everyone,

I've been working on Kheiron, an amalgamated, zero-dependency single-header CSPRNG library in C99/C11 built on top of ChaCha20 (RFC 8439), and I'd love to get feedback and code reviews from the community.

• GitHub Repository: https://github.com/cainamatera/kheiron

Why build this?

Most high-performance CSPRNG implementations either pull in the entire OpenSSL / libcrypto dependency tree (~7.8 MB binary footprint and dynamic runtime baggage) or provide scalar, single-block loops that struggle with high-throughput workloads.

Kheiron was built to be completely self-contained in a single file (kheiron.h, ~35 KB compiled) with:

1. Parallel Vectorization: An AVX2 kernel processing 8 parallel ChaCha20 blocks simultaneously (512 bytes per iteration), yielding up to ~2.5 GB/s on modern x86_64 CPUs.

2. Dynamic Runtime Dispatch: Automatic CPUID detection at runtime—no global -mavx2 compiler flags required. It falls back gracefully to pure scalar C99 on older x86, ARM, and RISC-V targets.

3. Continuous Forward Secrecy: Automatic key re-erasure every 1 MB without measurable throughput degradation.

4. Unbiased Uniform Sampling: Daniel Lemire’s nearly divisionless bit-multiplication method for integer intervals, plus IEEE 754 float/double conversion without modulo bias.

5. Strict Fail-Closed Entropy: Direct integration with OS entropy (getrandom, /dev/urandom, BCryptGenRandom) with zero weak jitter fallbacks.

Current Test & CI Coverage

• 235 E2E and adversarial tests passing across 12 GitHub Actions matrix jobs.

• Clean builds under GCC and Clang with -Wall -Wextra -Wpedantic -Werror.

• Full dynamic memory sanitization (ASan + UBSan) on Linux.

• Continuous AST semantic scanning via GitHub CodeQL (security-and-quality).

• Formal benchmarking methodology and reproduction steps documented in BENCHMARK.md.

Looking for:

• Feedback on low-level AVX2 instruction scheduling and ChaCha20 quarter-round unrolling.

• Edge-case testing on non-x86 platforms (e.g. Raspberry Pi, RISC-V, BSD).

• General critiques on API ergonomics and memory wiping routines.

Any thoughts, critiques, or PRs are warmly welcome!

Note: LLM tooling was strictly limited to editor autocomplete (scaffolding repetitive structs/typedefs) and proofreading markdown documentation and benchmark tables. All cryptographic state machines, RFC 8439 logic, runtime CPUID dynamic dispatch, manual AVX2 SIMD pipelines (instruction interleaving/register scheduling), and the 235 E2E test cases were designed, implemented, and mathematically verified entirely by hand.

Hey guys, so as the title already says, I have just gotten my first security advisory for my C project. I know its not really something to be proud of, or to brag about, but I already expected it, as its (atleast in my opinion) really difficult to have a bullet-proof program in C.

My project github.com/cherries-works/pulse has been in the making for more than 6 months now, and I always thought whether or not it was a smart decision making it open source, or whether or not it might have been smarter to keep it closed source, work on it on my own, release it under a commercial license yadda yadda. However, during my work hours, I checked into the repo real quick, just to find a security advisory laying there. It was not something too bad, it was a badly written parser for HTTP JSON requests on my written HTTP server.

Note that, this issue occurred even though I also added Vibe as a Pentester for my repository (locally). Meaning that (surprise surprise) even AI isnt that good with C.

The issue was that I was snprintf'ing a string with NULL args, and the value of the string that I was parsing included process names (the top ones / sorted by cpu/ram). Now that resulted in a user being able to create a process called "%s%s%s%s%s%s", and that passed into snprintf(...), with NULL args resulted in undefined behavior or more specifically as the publisher mentioned;

"In every run, the six %s specifiers are each consumed by snprintf thereby dereferencing whatever pointer value occupies the next variadic argument slot: (null) for null pointer, raw non-printable bytes for othres."

The problem;

```
snprintf(
response,
response_size,
json,
NULL
);
```

Where json was the char* json value passed into the routeJSON function. The fix was really simple.

```
snprintf(
response,
response_size,
"%s",
json
);
```

Not only did that show me that C still makes it realllyy easy to shoot yourself in the foot, it also made me appreciate open source a lot more. For anyone interested checking out the security advisory; https://github.com/cherries-works/pulse/security/advisories/GHSA-rhqf-rj5j-3v5r, as mentioned it is not really too bad (severity: low), regardless, I am still very glad that my project is open source, and glad that it is in C!

I guess I gotta be more careful with how I handle my stuff.

I started developing https://heapcrash.com initially to record some of the challenges(e.g. lcd render delay, nested mutex induced priority inversion, UART comm frame,etc.) that I experienced in last few years while working on embedded firmware. The idea turned out to the embedded concept library and further to an embedded interview prep. I have tried to put my 11 years of experience to conceptually design the site and develop it with the help of Claude over a few months.
I have added all sort of traditional categories and some of the newest ones to it.
I would like to get some reviews and feedback from my fellow embedded engineers on reddit for any improvements to it.

I've been writing a status bar for dwl in C. I'm posting it here more for the code than for the bar, so remarks on the C are welcome.

The renderer fills a `wl_shm` buffer itself, and the text goes through FreeType and fontconfig, which I call directly. The volume is a small client of the PulseAudio native protocol, talking to the socket of pipewire-pulse. The wifi name is read over netlink with nl80211. The other modules just read `/proc` and `/sys`.

Tell me what you would do differently.

Hey r/C_Programming,

Over the past few weeks, I decided to take a deep dive into computer networking by building my own reliable data transfer protocol (RDT) from scratch on top of raw UDP sockets — without any external libraries, just plain C11 and POSIX.

I named it Protocol-7 (P7) (yes, a small tribute to Serial Experiments Lain).

My main goal was not to "kill TCP", but to understand what actually happens under the hood when dealing with unreliable, lossy networks, rather than just treating TCP as a black box.

What is currently implemented:

• Sliding Window pipelining: 32-slot ring buffer keeping unacknowledged segments in flight.

• I/O Multiplexing via poll(): Non-blocking event loop handling file I/O, outgoing bursts, and incoming ACKs concurrently.

• Custom SACK (Selective ACK): Implemented via a 32-bit mask in the 16-byte header to report buffered out-of-order blocks.

• Fast Retransmit (RFC 5681): Triggers immediate retransmission upon receiving 3 duplicate ACKs without waiting for coarse RTO timers.

• 16-bit Word-Aligned Checksum: One's-complement arithmetic with end-around carry (spent quite some time debugging a weird bug caused by odd byte alignment!).

• Piggybacked FIN: Look-ahead double buffering allows setting the FIN flag on the final payload chunk without wasting a separate RTT on an empty packet.

• TIME_WAIT state: Receiver handles lingering packets and retransmissions gracefully before tearing down.

I also wrote a Python chaos proxy to inject simulated 5%–30% packet drops, data corruption, and duplicates. The protocol successfully transfers binary files byte-for-byte under heavy packet loss. The codebase runs completely clean under Valgrind (0 leaks, 0 errors) and AddressSanitizer.

Benchmarks & Fun Findings:

During testing, moving from Stop-and-Wait to a 32-slot Sliding Window bumped throughput from ~0.07 MB/s to over 1.85 MB/s under 5% packet loss (and ~66 MB/s on normal channel). I also hit a funny scenario where an oversized static window (512 slots) flooded the Linux kernel socket buffers, making lossy modes artificially faster than normal mode because the proxy drops acted as a crude rate limiter!

The project is open-source under MIT:
GitHub: https://github.com/by-cortex/protocol-7

I’d really appreciate any code review, constructive criticism on my C style, architecture feedback, or ideas on what to tackle next (currently planning a 3-way handshake with randomized ISN and dynamic RTO estimation).

Thanks for checking it out!

Recently, Elon said on X:

"We have dumped JAX/SGLang and rewritten the entire RL and inference stack from scratch in C/C++, which took some extra time.

Training (aka pre-training) is done. Lot of cleanup was needed on the SFT data to get that mostly right. Now, 4.8 is in RL and the evals are starting to climb. We will do a soft rollout to Bot users later this week and see how it goes.

Grok 4.8 will bear no resemblance to 4.7 (thankfully). It is not yet incredible, but, this time, the foundations are built right, so I expect it to evolve to be something special."

Someone questioned Elon: "Was it written in Rust? Why did you rewrite it in C/C++?"

Elon answered: "Real men manage their own memory. So easy to trigger Rust programmers

Rust is a good language, but C is what you use for optimal performance on bare metal. With great power comes great responsibility."

hahah, turns out Elon is C/C++'s strongest soldier

I built a Unix-style shell in C that exposes what's happening underneath

I've been working on P-Shell, a small Unix-style shell written in C.

The interesting part isn't just executing commands. I wanted to understand and expose the underlying Unix mechanisms.

It currently supports:

• "fork()" and "execvp()" based execution

• Pipes and output redirection

• File descriptor manipulation with "dup2()"

• An explanation mode that traces execution

• "/proc" process inspection

• Creating and reaping a real zombie process using "waitpid()"

I'm particularly interested in feedback on the implementation, parser design, process handling and what would be worth improving next.

Repository: https://github.com/punithk-verse/p-shell

I'd appreciate an honest technical review.

Would it be possible if I could intern(research work or any other type of work for free ofc) under anyone? I don’t have any experience for my resume as I’m a newbie.

I'm new to C programming so this is a genuine question

So c has 2 memory regions you can access

The stack and heap

People say that the heap is useful for creating data beyond the lifetime of the function and while it can be used for that a better solution would probably be to pass in a pointer an array on the stack if the max size is known ahead of runtime, I only use malloc when I don't have a definite max size for what I want and therefore have a need for reallocations, so that brings me to linear allocators, everyone is constantly singing there praises for making memory management easier while we already have the stack that can handle memory management for us 100% of the time and from there design I can't see a way to make a reallocation function for a linear allocator without it at the very least being highly thread unsafe.

And in general I don't see much of a reason to use the heap either because you rarely are in situations where you don't want to specify a max size for something

Wanting to learn C as an intro into software engineering. I know it’s low level and I’d like to eventually switch over to high level languages such as JS/TS, Java, and GO.

Does the “The Complete C Programming Bootcamp” course by Byte Garage be a good choice to learn from?

Hi, everyone!

I’m currently learning to program in C, and I want to become a good programmer without relying on AI to write code or solve problems for me. I feel really bad because I started my course off on the right foot, but due to my heavy course load, I ended up taking the easy way out and using AI assistants. I want to stop doing that and be able to program from scratch using my own knowledge, but of course, I’d rather ask here.

I’m looking for recommendations on:

Books, websites, or courses to learn C properly

Exercises and projects to improve my problem-solving skills

How to learn to debug and understand my own errors

How experienced programmers learned C before AI tools became popular

My goal is to understand the fundamentals of programming, develop my own logic, and be able to solve problems independently

Any advice or resources would be greatly appreciated. Thanks!

Translated with DeepL.com (free version)

I enjoy studying the realities and trade-offs of programming languages and I have my focus on the C programming language. As such I would like to hear from people who have programmed in C to share perhaps the things they love the most about C, or the things they find the most frustrating.

Examples on why things are frustrating or loved would be great to include as well.

Hi all,

I made Ugiwise, an iOS app for learning C on your phone. Typing code on a phone is a pain, so the lessons are built around reading it instead: you get a short program, guess what it does, then the app goes through it line by line and shows you why.

The C course follows C17 and goes from your first program to pointers, memory, multiple files and undefined behavior.

It's closed source. First 3 units are free, no account needed. The rest is a paid upgrade.

I asked the mods before posting and they were ok with a giveaway, so I have 10 lifetime codes. Leave a comment if you want one and I'll DM them in order until they're gone. Nothing expected in return.

What I'd really like to hear is where an explanation is wrong, sloppy about the standard, or just unclear. I compile the examples, but the compiler won't tell me if my explanation is bad.

A couple of limits, sorry about these:

- iOS only for now, no Android yet

- Not in EU App Stores yet (still waiting on Apple's trader verification). I'll do another 10 codes when it's out there.

https://ugiwise.com/c

App Store: https://apps.apple.com/app/id6828549507