Coder Legion - Recent posts tagged c

Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine

Fri, 23 Oct 2026 17:48:48 +0000

Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine

I built a meaning-learning engine that works without LLMs, embeddings, or
translation tables. Everything is stored as 2-bit ternary values {-1, 0, +1}.
It learns meaning purely from word co-occurrence in plain text.

What makes it different

No hard-coded linguistic knowledge. No stoplists, POS tags, tokenizer,
fixed vocabulary, or translation tables. All linguistic structure emerges
from training data.

Language-independent. Tested with English + Turkish. Same mechanism
works for any language with letter-based writing.

Ternary representation. {-1, 0, +1} — inhibition, unknown, excitation.
0 means "I don't know" — a first-class answer, not a failure.

Single decision rule. All thresholds come from each word's own
distribution. No hyperparameter tuning. (We call it "golden ratio freeze"
— referring to structural convergence, not φ = 1.618.)

Emergent morphology. After EN+TR dictionary training: 247 suffixes and
38 prefixes discovered automatically with zero linguistic rules.

Cross-language bridge. Without being told "water = su," the brain
forms bridges between equivalent concepts across languages. After 65 books:
average Jaccard 0.47, cosine 0.61 across 10 EN-TR word pairs.

How it works

Start with an empty brain
Train with monolingual dictionaries (word → definition)
Optionally add books/articles for richer meaning
Query: /compare water su, /map fire, /senses storm

The brain builds a sparse graph of word relationships. Multi-meaning words
split into separate sense layers automatically. Meaning groups emerge from
community detection on the neighbor graph.

Architecture

Layer	What it does
Concept neurons	Each word is a neuron with sparse ternary signature
Sentence neurons	Sentences become neurons linking words
Synapse graph	PMI-weighted co-occurrence connections
Sense layers	Dynamic multi-meaning, born from data
Topic groups	Community detection on neighbor graphs

Results (65 books trained)

Metric	Value
Concepts	288,407
Sentences	1,234,706
Synapses	102.7M
RAM	~1.3 GB

Cross-Language Bridge Examples

English	Turkish	Jaccard	Cosine
water	su	0.46	0.61
fire	ateş	0.35	0.57
king	kral	0.46	0.56
sea	deniz	0.49	0.60
moon	ay	0.43	0.67

What this is NOT

Not an LLM — no attention, no transformer, no text generation
Not open source — binary-only experimental release
Not a pretrained model — you train from scratch with your own data
Not AGI — no claims of consciousness or general intelligence

Try it yourself

git clone https://github.com/arifkurnaz/ternary-semantic-brain-demo
cd ternary-semantic-brain-demo
chmod +x scripts/linux/*.sh
./scripts/linux/02_train.sh --dict

Linux binary included. Windows via WSL2.
Full paper and architecture docs in the repo.

The missing break behind Digimon World’s evolution rules

Fri, 16 Oct 2026 19:39:38 +0000

title: The missing break behind Digimon World’s evolution rules
published: true
description: Digimon World’s decompiled evolution code reveals a four-point scoring system, a surprising tie-break rule, and a path toward a PC port.

tags: reverseengineering, c, gamedev, cpp

You fed it, trained it, cleaned up after it. You had a plan. Then it evolved into Numemon, a walking pile of sludge, and the game never told you why.

No menu. No hint. No stat screen saying here is what went wrong.

Players filled that silence with wikis, calculators and arguments about whether care mistakes helped or hurt. They inferred the rules from what happened on screen. Now we can read the code.

The Digimon World decompilation project has reconstructed the evolution code. One rule comes from a loop with no break: when several stats share the highest value, the game picks the last one in its array.

Here is how the scoring works, what that tie means, and what I learned while testing a small PC port prototype.

The missing break

Here is the real code that picks which of your stats the game examines. It's in src/main/evolution.c, and it runs over the six stats hp, mp, offense, defense, speed, brain:

for (i = 0; i < 6; i++) {
  int8_t isHighestStat = 1;
  for (j = 0; j < 6; j++) {
    if (statsArray[i] < statsArray[j])
      isHighestStat = 0;
  }
  if (isHighestStat == 1)
    highestStat = i;
}

For six stats, the nested loop is cheap. But look at what is missing: there is no break after the assignment. The loop keeps going after it finds a maximum, so a later tied stat overwrites an earlier one. When stats tie, the highest index wins.

I ran the same selection logic with a few inputs:

all six tied      -> brain
offense highest   -> offense
off+def tied high -> defense
brain highest     -> brain

Reading the array order backwards gives the full tie-break priority: brain > speed > defense > offense > mp > hp.

With all six stats tied, the game selects brain as the highest stat. You could infer this from enough experiments, but the code makes the reason clear. Whether the missing break was intentional is unknown; its effect is observable.

{% card %}
Worth being careful here: I first suspected highestStat was read uninitialized, which would be a genuine bug worth reporting upstream. It can't be — a maximum always exists among six values, so the flag is always set at least once. Check before you claim.
{% endcard %}

The scoring system: four checks, three needed

That tie-break feeds a larger system. Every Digimon has up to six possible evolution targets. For each candidate the game computes a score out of 4, and a candidate needs at least 3 points to be eligible at all. Below 3 it isn't considered.

Here are the four checks.

Care mistakes, and the flag that inverts them

if (isMaxCM == 0) {
  if (partner->careMistakes >= reqs->care)
    reqPoints += 1;
} else if (partner->careMistakes <= reqs->care) {
  reqPoints += 1;
}

Read the comparisons closely. There's a flag bit that reverses the test, so some evolutions want your care mistakes above a threshold.

Neglect isn't a punishment in this game. For certain paths it's a requirement. Care mistakes can therefore help qualify a candidate. Whether that explains any particular Numemon depends on the other checks and available targets.

Weight is a window, not a floor

if (reqs->weight - 5 <= partner->weight &&
    partner->weight <= reqs->weight + 5)
  reqPoints += 1;

A band of ±5 around a target. Overfeeding fails this check exactly as hard as underfeeding. A precise target weight matters because both sides of the window have a limit.

Stats, where the stage changes the rule

if (DIGIMON_DATA[target].level == 3U) {
  /* Champion: only your single HIGHEST stat is examined */
} else {
  /* everything else: ALL six stats must clear their thresholds */
}

Most evolutions need every stat above its requirement. Champion-level targets check only your highest one — which is where the missing break above actually bites. For Champions, one selected highest stat matters; other targets require all six thresholds.

The bonus point: any one of five

if (reqs->digimon    != -1 && current == reqs->digimon) isBonusFulfilled = 1;
if (reqs->discipline != -1 && /* ... */)                isBonusFulfilled = 1;
if (reqs->happiness  != -1 && /* ... */)                isBonusFulfilled = 1;
if (reqs->battles    != -1) { /* also invertible */ }
if (reqs->techs      != -1) { /* mastered moves */ }

Any single one of these grants the fourth point. Battle count carries the same inversion trick as care mistakes: some evolutions want you to have fought fewer than N battles.

The rule that quietly steers your collection

One more piece, and it's the one that made me sit back:

if (reqPoints >= 3 && currentBest != -1) {
  isTargetRaised = hasDigimonRaised(
      EVO_GAINS_DATA[target].targetDigimon);
  isCurrentBestRaised = hasDigimonRaised(
      EVO_GAINS_DATA[currentBest].targetDigimon);

  if (isTargetRaised == 1 && isCurrentBestRaised == 0)
    reqPoints = 0;      /* you already have this one: disqualify it */

  if (isTargetRaised == 0 && isCurrentBestRaised == 1)
    reqPoints++;        /* you don't have this one: push it ahead */
}

The game remembers which Digimon you have raised. When it compares two eligible candidates, this code favours the one you have not raised: it can zero the already-raised candidate’s score or add a point to the new one. The outcome still depends on candidate order and the surrounding selection logic.

It is a small but deliberate way to steer players toward more of the roster.

Who actually did this

I did not decompile the game. I forked the repository, ran parts of its code on a PC, and measured a few pieces a port would need. The decompilation work belongs to its contributors.

{% embed https://github.com/jype0/dw_decomp %}

jype0/dw_decomp started in March 2026 and is MIT licensed. It passed a milestone most decompilation projects never reach: zero INCLUDE_ASM stubs left in src/.

If you haven't worked on a decomp, that needs explaining. INCLUDE_ASM is the marker for "we haven't figured this function out yet, here's the raw assembly instead." Most decomps carry hundreds of them for years. The source tree no longer relies on those assembly placeholders. That milestone alone does not establish that every function matches the retail binary.

Credit isn't evenly spread, and shouldn't be reported as if it were. As of today the contributor counts are:

Contributor	Contributions
Pekka Jylhä-Ollila (jype0)	409 — maintainer, and the bulk of the project
juandav	37 — matching functions and data across overlays
ChonkMode	22
kingzmanh	11
fmil95	7
ThirstyWraith	6
SydMontague	5 — struct and naming reference work
paulohpfilho	4

Those are the repository’s contribution counts at the time I checked, not a measure of each person’s work or proof that every regional build is complete.

I asked about the roadmap in an issue. juandav relayed jype0's four points: clean up the hacks and name things properly; match all 10 regional versions; maybe a PC port, blocked because psyq and psycross don't currently implement libgs or libsnd; and then a DW1 mod of epic proportions — new maps, story, Digimon.

The ambitious mod is the long-term goal. The decompilation makes that work possible.

Running their code somewhere it has never run

My question was narrower: can this code run off the PlayStation at all?

evolution.c is 1,087 lines. Compiling it on x86-64 produced exactly one error:

libgte.h: No such file or directory

That's Sony's geometry coprocessor header. So I grepped evolution.c for VECTOR, MATRIX, gte_, RotTrans — nothing. The evolution logic doesn't touch the GTE at all. It only inherits the header through entity.h.

I wrote type-only stand-ins for the four PsyQ headers. It compiled clean, then ran:

EvoRequirements = 28 bytes (PS1 layout: 28)
fresh(1)       -> 2
in-training(3) -> 5

That 28 matters more than it looks. The game reads its data tables as raw structs, so if the layout shifted by even one byte on a 64-bit host, every evolution requirement in the game would decode as noise. It doesn't, and I pinned it with static_assert so nobody can break it quietly later.

Measuring the GTE instead of guessing at it

A major piece of a PS1 port is the GTE, the fixed-point geometry coprocessor.

My first instinct was to size the problem with a grep. I got 181 and quoted that number publicly. It was wrong — my pattern was matching a header that defines every GTE macro whether the game calls it or not. Measured against src/ alone:

632 call sites, 29 distinct operations, 34 of 126 files

The call sites are concentrated:

Operation	Sites	Cumulative
`ApplyMatrixSV`	103	16%
`RotMatrix`	51	24%
`RotMatrixZYX`	44	31%
`RotMatrixYXZ`	44	38%
`ratan2`	43	45%
`gte_rtps`	42	58%
`ScaleMatrix`	39	71%
`TransMatrix`	37	77%
`ApplyMatrixLV`	23	81%

The nine operations shown account for about 81% of these call sites. That gives a useful starting point, though call-site count does not measure implementation difficulty.

I implemented a software subset covering those common operations. The contract is strict: matrix entries are 1.3.12 fixed point (4096 = 1.0), angles run 4096 to a full turn, and results saturate rather than wrap. That last one isn't optional — a wrapped coordinate throws a vertex to the far side of the screen, which is exactly the class of bug that ships unnoticed.

Then I measured the number that actually decides anything. "0.17% trigonometric error" is a useless statistic; nobody can tell you whether that's visible. So I measured pixels — how far a projected vertex lands from where double-precision maths puts it, across 2,528 vertices and a full rotation sweep:

mean error:             0.825 px
worst error:            1.896 px
vertices off by > 2px:  0.00%

In that test, the error stayed under two pixels. This measures one projection sweep; it does not guarantee every game scene will look the same.

And the honest half: it is not bit-exact. The real GTE uses lookup tables; my polynomial approximation looks identical and is numerically different. That's fine for a port and useless for verifying a decompilation, whose entire premise is reproducing the original binary byte for byte. Confusing those two would be the expensive mistake, so I put the warning in the test output rather than in a comment nobody reads.

{% details Drawing a frame: primitives and the ordering table %}

The game's rendering is all PsyQ primitives, counted across the source:

POLY_FT4  386    (textured quad)
POLY_F4    30
POLY_GT4   17
POLY_FT3    6    (textured triangle)

The two textured primitive types in this excerpt account for 392 call sites, making them a useful first rendering test. I built them with the game's own setXYWH and setUVWH macros lifted from src/main/utils.c, and rasterised them in software.

One thing I deliberately did not fix: the texture mapping is affine, not perspective-correct. The PS1 had no perspective correction, and that wobble is part of how the console looks. Correcting it would make a port feel wrong.

Then the ordering table, which is how the PS1 sorted by depth. The name misleads, so it's worth saying plainly: an ordering table is not a sorting algorithm. It's a bucket array — one slot per depth value, each holding a linked list, with AddPrim pushing to the front. O(1) insertion, zero comparisons. That's how a 33MHz console depth-sorted a scene every frame, and reimplementing it with qsort would be slower and wrong, because the order of equal-depth primitives depends on the original insertion and traversal rules.

I built the occlusion test so it couldn't pass by luck: submit the near quad first, then the far one.

normal:          centre pixel r=16  g=104    (near/green occludes)
depths swapped:  centre pixel r=120 g=16     (far/red now occludes)

Same submission order, opposite result. The table is doing the work, not the sequence of my function calls.

{% enddetails %}

Where I got things wrong

Two corrections, because they're more useful than a clean story.

The GTE count. I said 181 in public. It's 632. I estimated with a grep and then quoted the estimate as a measurement, which is a bad habit and I did it anyway.

A test that failed for the right reason. I asserted the far square would peek out around the near one. It doesn't: the near quad spans x=75..245 and the far one x=123..197, so full occlusion is correct physics and my sampling point was badly chosen. I checked the rendered image before touching any code, which is the only reason I didn't "fix" working code to match a broken expectation.

What this does not prove

One logic file out of 126. I picked evolution.c because it looked dependency-free. Best case, not a representative sample.
The GTE is approximate. 18 of 29 operations unimplemented, and the trig is polynomial rather than table-driven.
No model loading. GsSortObject4 has 42 call sites and walks TMD models. The ordering table is ready for it; the format reader isn't written.
Nothing validated against the retail binary. That needs the MIPS toolchain and a disc image.
The assets are still Bandai's. Models, textures, music, text. A possible distribution model is an engine that requires players to supply their own game data; the legal details would need separate review.

Where my work and jype0's roadmap touch: his stated blocker for a PC port is that psyq and psycross don't implement libgs or libsnd. libgs is one of the four headers I stubbed. I'm not claiming that solves his problem — only that it's the same wall, and it's climbable from at least one side.

What we finally understand

Twenty-five years of wiki edits, spreadsheets and arguments, and the answer is a few hundred lines of C:

3 points of 4 to be eligible at all
Care mistakes and battle counts are invertible — some evolutions want neglect
Weight is a ±5 window — overfeeding fails like starving
Champions check your highest stat only; everything else checks all six
Ties favour the last tied stat in array order, with brain last
Previously raised targets can lose a head-to-head comparison against a new one

Your Numemon had an explanation in the game’s rules. The exact reason in any given run depends on the candidate scores and selection path.

That is what makes the decompilation exciting: the rules are readable and testable. It also gives modders a foundation to build on.

My four experiments live on a branch in my fork. Each runs with one command and needs only gcc, plus libsdl2-dev for the two that draw — no PlayStation toolchain, no disc image.

If you've worked on a decomp: how do you decide when an approximation is good enough to ship in a port, given it can never be good enough to verify a match? The bit-exact line is the part I'm least sure I drew correctly.

My Journey with C++: Building Efficient and Reliable Software

Mon, 12 Oct 2026 02:41:51 +0000

As a C++ developer, I enjoy solving complex problems, writing clean code, and building software that performs efficiently. For me, programming is not just about making something work; it’s about understanding how it works and finding better ways to solve problems.

Why I Enjoy Working with C++

C++ is a powerful language that teaches me to think deeply about programming. From memory management to data structures and algorithms, it helps me understand what happens behind the scenes and how software can be made faster and more reliable.

I enjoy exploring different approaches to a problem, improving performance, and writing code that is easier to maintain.

What I Focus On

My main interests include:

C++ programming and object-oriented programming
Data structures and algorithms for solving complex problems
Memory management and performance optimization
Problem solving through logical thinking and efficient coding
Software development with a focus on reliability and maintainability

Learning Never Stops

Technology continues to evolve, and there is always something new to explore. I believe becoming a better developer requires continuous learning, practical experience, and the willingness to learn from mistakes.

I enjoy experimenting with new ideas, improving my programming skills, and learning from other developers who share the same passion for technology.

I believe that sharing knowledge helps us grow together and discover better ways to develop software.

Always learning, always coding, and always looking for better ways to solve problems.

Assembly language

Fri, 02 Oct 2026 20:40:11 +0000

Yo everyone, this is my first post and I wanna talk about assembly.

So back in 1962, the US launched Mariner 1 to Venus. A few mins after liftoff, the rocket started going off course, so they had to blow it up. Turns out it was a code bug: in an assembly program (or something close to it), they missed one little bar over a letter in a formula. Instead of smoothing the trajectory, the program started wobbling it. Cost of that mistake? Like 18.5 million bucks (in that era's money) and a dead mission. Since then, people bring it up as proof that even one symbol in low-level code can cost you a whole rocket.

So yeah, I honestly don't get those "mutants" in programming who write in assembly. I got one buddy who codes in assembly, and we don't even talk anymore (maybe that's part of why lol). Anyway, I'm learning C myself and wanna be a systems programmer, and I got no clue how I'm gonna learn assembly — just so you know, it's right below machine code. Btw, assembly is a super hard language that eats up tons of time. But there are way more Python jobs (and neural nets will take those anyway) than assembly jobs. In the end, I just respect people who know it.

Good luck everyone, catch you later

How to Write to Web.config in Medium Trust

Fri, 02 Oct 2026 03:37:53 +0000

If you’re working with an older ASP.NET application running under Medium Trust, you may run into a common problem: your application can read Web.config, but attempting to modify it at runtime fails with a security or permission exception.

The important point is that Medium Trust is designed to restrict applications from modifying configuration files. Simply using Server.MapPath() and File.WriteAllText() is not a reliable solution—and in a hosted environment, it will generally be blocked by filesystem permissions or the trust policy.

What can you do?

If you need to change configuration dynamically, consider these approaches:

Store dynamic settings outside Web.config

Instead of modifying Web.config, use a data store such as a database or another configuration mechanism that your application is allowed to write to.

// Example: store application settings in a database
string value = GetSettingFromDatabase("MySetting");

Use an application-level configuration file

For settings that need to be writable, keep them in a separate file, provided your hosting environment allows your application to create and modify that file.

string path = Server.MapPath("~/App_Data/settings.xml");

File.WriteAllText(path, "Value");

App_Data is commonly used for application data because it isn't intended to be served directly to clients.

Change Web.config during deployment

If the configuration really belongs in Web.config, the safest approach is usually to modify it as part of your deployment process rather than from application code.

For example:

Your deployment process can generate or transform the appropriate configuration for each environment.

What about ConfigurationManager?

You can read configuration values normally:

string value =

ConfigurationManager.AppSettings["MySetting"];

But being able to read configuration doesn't mean the application has permission to write the physical Web.config file.

Bottom line

Under Medium Trust, don't design your application around runtime modification of Web.config. If a value needs to change while the application is running, keep that value in a writable data store or separate configuration file. If it belongs in Web.config, update it during deployment.

This approach is more secure, more predictable, and works better with hosted ASP.NET environments.

Writing a Programming Language & Native x86-64 Compiler from Scratch in C: The Story of Yolish

Sun, 27 Sep 2026 03:56:49 +0000

Every programmer has, at some point, looked at their favorite programming language and thought:

“Why was it designed this way? How hard can it actually be to build one myself?”

Most developers who explore language design stop at simple arithmetic evaluators or toy interpreters. But when I was building Exploidus OS—a custom x86-64 reactive capability operating system—I ran into a fundamental architectural barrier:

Standard systems languages (like C) have zero concept of operating-system capability tokens. In C, if you have a pointer, you can dereference it. If you have an address space, any line of code can call any syscall unless restricted by complex external sandboxes.

I wanted a modern, expressive language that felt as ergonomic as Python or Rust, but was deeply capability-aware at the syntax level—able to compile directly to bare-metal x86-64 binaries without pulling in gigabytes of LLVM dependencies.

That ambition gave birth to Yolish—a fast, expressive, capability-aware programming language with a tree-walking interpreter, a bytecode virtual machine, and a direct x86-64 native compiler.

Here is how I designed Yolish, wrote its compiler from scratch in pure C, and what I learned building a complete language ecosystem.

1. Language Design: Ergonomics Meets Systems Control

When designing Yolish's syntax (.y), I wanted code to read cleanly without syntactic noise, while enforcing defensive systems programming invariants.

Immutability by Default

Variables in Yolish default to immutable constants using let, while mutable state must be explicitly declared using var:

let name  = "Yolish"   -- immutable constant
var count = 0          -- mutable state
count = count + 1

Pattern Matching with Ranges & Guards

Instead of archaic C-style switch statements with fallthrough bugs, Yolish features expressive pattern matching:

let grade = match score {
    90..100      => "A"
    80..90       => "B"
    n if n >= 60 => "C"
    _            => "F"
}

Structs and `impl` Blocks

Yolish rejects complex class hierarchies in favor of data-first structs and explicit method implementations:

struct Circle { radius }

impl Circle {
    fn area(self) {
        return y.math.pi * self.radius * self.radius
    }
}

let c = Circle { radius: 5 }
y.println(c.area())

2. Bridging Code to the Kernel: First-Class Capabilities

Because Yolish is the official userspace language for Exploidus OS, security cannot be an afterthought.

In Yolish, dangerous operations (network access, raw disk writes, peripheral I/O) are gated by declarative capability annotations:

@cap(net.read, fs.write)
fn sync_data(url, filepath) {
    let payload = y.net.get(url)
    y.fs.write(filepath, payload)
}

When compiled for Exploidus OS, the Yolish compiler inspects these annotations and validates them against the process's cryptographic capability table. If an unprivileged function attempts to make an unauthorized syscall, the operation is blocked before execution even reaches kernel space.

3. The Tri-Engine Architecture: Interpreter, Bytecode VM, and Native Compiler

Building a language engine involves tough tradeoffs. Tree-walking interpreters are easy to write but slow. Bytecode VMs are fast and portable. Native compilers deliver maximum speed but are deeply architecture-specific.

Instead of choosing one, Yolish implements all three:

Source Code (.y)
       |
    [Lexer] -> Tokens
       |
   [Parser] -> Abstract Syntax Tree (AST)
       |
       +---> Tree-Walking Interpreter  (`ys file.y` - Instant startup)
       |
       +---> Bytecode Compiler & VM    (`ys vm file.y` - High speed execution)
       |
       +---> Direct x86-64 Machine Code (`ys -c file.y` - Standalone binaries)

The Interactive Interpreter (ys file.y): Evaluates the AST directly. Perfect for quick scripts, one-liners, and the interactive REPL.
The Bytecode VM (ys vm file.y): Compiles the AST into an optimized instruction stream executed by a custom register/stack-based virtual machine.
The Native x86-64 Compiler (ys -c file.y): Generates real machine code instructions (MOV, ADD, CALL, RET, SSE2 float operations) directly into executable binary containers.

4. No LLVM, No Bloat: Direct Multi-Platform Binary Emission

Most modern compiler projects delegate code generation to LLVM. While LLVM is powerful, it is also a massive, multi-gigabyte dependency with slow compilation times.

I wanted the Yolish toolchain (ys) to be a single, self-contained C binary with zero external dependencies. You can clone the repo and compile the entire language toolchain with a single make command using standard gcc or clang in seconds.

To achieve this without LLVM, Yolish writes binary headers and machine code directly:

Linux ELF64: Directly formats ELF headers, program headers (PT_LOAD), .text sections, and Linux syscall dispatchers.
Windows PE32+: Generates valid Portable Executable (PE32+) headers, image import directories, and embeds Windows application icons.
macOS Mach-O: Generates 64-bit Mach-O load commands (LC_SEGMENT_64).

You can cross-compile for any major operating system with a single CLI flag:

ys -c app.y --target linux    # Emits static Linux ELF64 binary
ys -c app.y --target windows  # Emits Windows PE32+ .exe
ys -c app.y --target macos    # Emits macOS Mach-O binary

5. Runtime Architecture: Mark-and-Sweep Garbage Collection

A systems language with dynamic strings and closures needs safe, automatic memory reclamation.

Yolish implements a custom Mark-and-Sweep Garbage Collector (GC) written from scratch in C:

Root Scanning: Traverses the active call frame stack, global environment variables, and the VM operand stack to identify all actively reachable pointers.
Mark Phase: Recursively traverses heap-allocated objects (strings, dynamic arrays, closures, struct instances), setting the GC mark bit.
Sweep Phase: Scans the global heap allocation pool. Any block whose mark bit is zero was unreachable; it is freed back to the system memory pool, while surviving objects have their mark bits cleared for the next cycle.

Developers have full programmatic introspection into memory usage via gc.stats() and can trigger explicit collection via gc.collect().

6. A Tooling-First Philosophy

A great programming language is more than just a syntax parser; it is an entire developer experience.

Too many new languages fail because they require third-party formatters, linter plugins, and package wrappers before you can write a serious project.

From day one, Yolish was designed with a tooling-first philosophy:

Built-in Test Runner (ys test file.y): Write native test blocks alongside code and execute them without third-party frameworks.
Static Checker (ys check file.y): Performs static semantic analysis, flags undefined variables, and detects type mismatches before runtime.
Code Formatter (ys fmt file.y): Enforces an opinionated, canonical code style across codebases.
Interactive REPL (ys): Instant feedback loop with color-highlighted evaluation.

7. What Writing a Compiler in C Teaches You

Writing a programming language and compiler from scratch in pure C is one of the most humbling and rewarding journeys in software engineering:

Memory Discipline: Managing AST nodes, symbol tables, and lexical scopes in C forces you to understand every single byte you allocate. Memory leaks in a compiler slow down compilation; memory corruption in code generation crashes the output binary.
The Magic of Abstraction: When you write the code that translates a simple if (x > 10) into a CMP and JLE assembly jump, you demystify how computers actually think. You realize that high-level abstractions are not magic; they are just structured transformations of intent.
Simplicity Over Complexity: Features are easy to add to a grammar; keeping the language coherent, orthogonal, and bug-free across interpretation and native compilation is where the real engineering happens.

Conclusion & Open Source

Yolish started as a specialized language project for Exploidus OS, but has evolved into a versatile, cross-platform programming environment with its own native compiler, VM, and standard library.

The entire project is 100% open-source under the MIT license:

GitHub Repository: https://github.com/rahadbhuiya/Yolish
Supported Platforms: Linux, Windows, macOS, and Exploidus OS.

Download the binary, try out the REPL, write a script, and inspect the C compiler source!

Have you ever thought about designing a programming language? What is the one feature you wish your daily language had? Let's discuss in the comments below!

Building an x86-64 Operating System from Scratch in C: The Exploidus Story

Fri, 25 Sep 2026 04:33:00 +0000

Most software engineers spend their careers working high up the abstraction ladder: web frameworks, containers, virtual machines, and cloud APIs. We treat the operating system as an invisible, infallible foundation. We assume malloc() will magically allocate RAM, write() will reliably flush bytes to disk, and the CPU will seamlessly multiplex threads.

A few years ago, I decided to pull back the curtain and ask a fundamental question:

What actually happens if you strip away Linux, Windows, libc, and every single runtime library, and sit directly on the bare metal of an x86-64 processor with nothing but C and assembly?

That question led to Exploidus—a custom x86-64 reactive capability operating system kernel built completely from scratch.

Today, Exploidus boots via Multiboot2/GRUB, runs in full 64-bit long mode, implements 4-level paging with NX enforcement, features a custom journaling filesystem (ExFS), runs an in-kernel TCP/IP stack with real Gigabit Ethernet drivers, enforces BLAKE3 cryptographic capability tokens, supports 82 POSIX-style syscalls, and even powers a double-buffered userspace window compositor.

Here is the story of how I designed and built it, the architectural hurdles I faced, and what bare-metal systems programming teaches you about software engineering.

The Starting Line: From Real Mode to 64-Bit Long Mode
When an x86-64 processor powers on, it does not wake up as a modern 64-bit machine. It awakens in 16-bit Real Mode, essentially pretending to be an Intel 8086 from 1978 with 1 MB of addressable memory.

To get Exploidus running, the bootloader transition had to be orchestrated meticulously:

Multiboot2 Compliance: The kernel binary begins with a Multiboot2 header so GRUB2 can discover and load our ELF64 image into memory.
Transitioning Modes: Moving through 32-bit Protected Mode, setting up the Global Descriptor Table (GDT), enabling Physical Address Extension (PAE), and finally setting the Long Mode Enable (LME) bit in the EFER model-specific register.
Entering Long Mode: Once paging is turned on and a 64-bit GDT code descriptor is loaded, a far jump lands execution into pure 64-bit Long Mode.
At this stage, you have no printf, no standard library, and no memory allocator. If a pointer dereferences wrong, the CPU triple-faults and the machine instantly reboots in a split second.

The first milestone of any OS developer is the VGA text-mode driver at physical address 0xB8000. Writing characters directly into video memory bytes and watching the word Exploidus Kernel Initializing... render on a blank screen is a sensation every programmer should experience at least once.

Memory Architecture: 4-Level Paging and Colored Zones
Virtual memory is the bedrock of process isolation. Without it, any runaway pointer can overwrite the kernel or another process's state.

In Exploidus, memory management is divided into two core layers:

4-Level x86-64 Paging
Exploidus uses the standard x86-64 page-table hierarchy:

PML4 (Page Map Level 4)
PDPT (Page Directory Pointer Table)
PD (Page Directory)
PT (Page Table)
Every page entry manages a 4 KB physical frame. To enforce strict security:

NX (No-Execute) Bit Enforcement: All data, heap, and stack pages are flagged with the XD/NX bit (bit 63). Code cannot execute from the stack or heap, neutralizing classic buffer overflow shellcode attacks at the hardware level.
User/Supervisor Protection: Kernel space is mapped into the higher half and strictly protected by disabling the User bit (U/S = 0), preventing Ring 3 userspace applications from reading or writing kernel data structures.
Colored Physical Frame Allocation
Instead of a naive linear allocator or a slow buddy system, Exploidus introduces a Colored Zone Physical Memory Manager:

GREEN ZONE: Unrestricted, verified general-purpose memory for userspace processes.
YELLOW ZONE: DMA-capable and peripheral-bounded memory mapped for hardware device drivers (e.g. NIC ring buffers, USB host controllers).
RED ZONE: Cryptographically isolated, non-swappable physical frames reserved strictly for kernel capability tokens, master page tables, and audit logs.

Capability Security & Crash Isolation
Most commodity operating systems rely on ambient authority (e.g. standard UID/GID or Unix permissions). If a process runs as root, it can execute anything.

Exploidus explores a Reactive Capability-Based Security Model:

Resources (file descriptors, sockets, physical devices, IPC channels) are gated behind unforgeable capability tokens.
Hardware-Seeded BLAKE3 Tokens: Tokens are generated by hashing resource pointers and generation counters using the BLAKE3 cryptographic algorithm, seeded with random entropy directly from the CPU's RDRAND instruction.
Crash Isolation: If a userspace process suffers a segmentation fault, divides by zero, or triggers an invalid opcode, the kernel does not panic. The CPU interrupt handler traps the exception, destroys the faulting process's capability table, reclaims its address space, and terminates only that process. The shell and the rest of the OS continue running uninterrupted.

Designing a Custom Filesystem: ExFS
You cannot have a functional operating system without persistent storage. While many hobby kernels stop at read-only tar ramdisks or FAT12, Exploidus features its own custom filesystem: ExFS.

Key Architectural Elements of ExFS:
Generic Block Device Layer: An abstraction layer (blockdev.c) decouples storage hardware from the filesystem. Whether a volume is an IDE/ATA hard drive (ata0) or a USB thumb drive (usb0), ExFS interacts through unified sector read/write interfaces.
Metadata Journaling: ExFS uses a write-ahead metadata journal to ensure crash consistency. Directory modifications, inode allocations, and block allocations are recorded in a circular journal before being committed to disk structures. If a sudden power loss occurs, replay recovery restores volume consistency upon reboot.
Data Provenance: Inodes in ExFS carry immutable provenance records, tracking the creator capability and timestamp of creation to provide built-in forensic audit trails.

Drivers from the Metal: USB and Gigabit Ethernet
Writing device drivers without third-party libraries or Linux helper APIs is where hardware reality hits you hardest. Data sheets for real silicon can be hundreds of pages long and filled with subtle timing quirks.

UHCI USB Subsystem
Exploidus includes a custom UHCI (Universal Host Controller Interface) USB driver:

Probes PCI configuration space to discover USB host controllers.
Configures physical memory transfer descriptors (TDs) and queue heads (QHs) in DMA-accessible memory.
Implements USB device enumeration, Control, Interrupt, and Bulk endpoints.
Supports USB Mass Storage (Bulk-Only Transport + SCSI command wrappers), allowing developers to plug in a USB flash drive, mount it into the VFS, and read files via the shell.
Gigabit Networking & In-Kernel TCP/IP Stack
Exploidus features an in-kernel network stack communicating through an Intel 82540EM (e1000) Gigabit Ethernet controller:

Layer 2: Ethernet frame parsing and ARP table resolution with cache expiration.
Layer 3: IPv4 parsing, checksum calculation, and IP fragment reassembly.
Layer 4: ICMP (ping echo reply/request), UDP, and full TCP state machine (three-way handshake SYN -> SYN-ACK -> ACK, sequence/acknowledgment tracking, window scaling, and packet retransmission).
Because the TCP/IP stack runs natively inside the kernel, userspace processes can issue POSIX-like socket(), connect(), send(), and recv() syscalls to communicate over the real local network.

From the exploish Shell to a GUI Compositor
An OS needs an interface to be useful. Exploidus provides two layers:

The exploish Interactive Shell
exploish runs as a Ring 3 userspace process, executing commands via system calls:

ps: Inspects real kernel process tables, priorities, and execution states.
audit: Reads cryptographic audit log entries directly from the kernel.
mount / ls / cat: Traverses and manipulates the ExFS filesystem.
The alien Window Compositor
Moving beyond text mode, Exploidus includes a userspace graphical compositor called alien:

Utilizes VESA / Linear Framebuffer modes discovered via Multiboot.
Single-Syscall Window Blitting (SYS_FB_BLIT): Minimizes user-to-kernel context switching during rendering.
Double-Buffering & Dirty-Region Redraws: Windows maintain their own back-buffers in userspace; the compositor only copies modified bounding boxes to the screen buffer, providing flicker-free rendering with real-time frame pacing.

What Building an OS Taught Me
Writing an operating system from scratch over months and years completely reshapes how you look at software engineering:

Hardware is not clean; it is quirky: Silicon behaves in strange ways. Concurrency is not just threads racing; it is hardware interrupts firing in the middle of a critical pointer assignment. You develop an immense respect for atomic operations, IRQ-safe spinlocks, and memory barriers.
Abstractions have a real cost: When you have to write your own kmalloc(), page fault handler, and scheduling timer, you realize that memory allocations and context switches are not free. High-level frameworks often hide enormous amounts of churn.
Debugging without tools builds discipline: When you don't have GDB or stack traces, and an invalid memory write freezes the CPU instantly, you learn to reason through your code with mathematical precision. You read every line, analyze register states, and build defensive invariants.
Conclusion & Open Source
Exploidus started as an ambitious experiment in Bangladesh to explore what it takes to build an operating system from zero without relying on existing Linux codebases. Today, it stands as a fully documented, open-source x86-64 capability kernel with a rich ecosystem of drivers, filesystems, and networking.

If you are interested in OS development, systems programming, or seeing how an x86-64 kernel works under the hood, the entire codebase is open-source:

GitHub Repository: https://github.com/rahadbhuiya/Exploidus
Feel free to star the repo, clone it, run it in QEMU, or read through the kernel source!

Have you ever experimented with operating system development or bare-metal programming? What was the hardest low-level bug you ever encountered? Let's discuss in the comments below!

Exploiting "Trust-by-Default": How I transformed an ESP32-S3 into a BadUSB

Sat, 12 Sep 2026 14:58:38 +0000

The first tool I decided to arm my Swiss army knife with was a BadUSB emulator. First and foremost, this extremely powerful tool (provided you have physical access to the target machine) relies on an inherent vulnerability of the USB protocol (born in 1996), originally designed to make connecting peripherals as simple and invisible as possible.

Practically, when we plug a USB device into a computer, a rigorous process called Enumeration begins. This is divided into several phases: the device is physically connected, its communication speed is identified, and immediately after, the device sends its Descriptors. These descriptors are a set of vital information that defines how the host machine will communicate with the device; subsequently, the device is reset, an address is assigned to it, the interfaces are loaded, and finally, the drivers.

(If you want to delve deeper into the enumeration phase, I recommend this article by TotalPhase).

Having defined this, it's easy to guess that if we alter the descriptors via software, we can disguise an ordinary flash drive (or in our case, an M5Stick) making it appear as a keyboard or a mouse.

And this is where the "Trust-by-Default" vulnerability comes into play: all operating systems blindly trust an HID (Human Interface Device) like a keyboard, as it is an essential input tool. Generic drivers are already pre-installed in the kernel (zero incompatibilities or warning popups) and, moreover, antiviruses have no say in the matter, since they are not designed to scan hardware inputs sent via electrical impulses.

The architectural choice: Dynamic Parser vs Hardcoding

Initially, for "simplicity", I thought about hardcoding the payloads directly in the C source code. But thinking about it carefully, the use cases in pentesting are infinite: the end-user must have the ability to modify scripts on the fly, without having to recompile or flash the ESP32 firmware every time.

For this reason, I decided to implement a dynamic Parser for DuckyScript. This allows the user to upload their own plain text scripts (.txt) onto the device's LittleFS memory and have the microcontroller interpret them on the fly.

For those unfamiliar with it, DuckyScript is a macro language created by Hak5 that abstracts interaction with the victim machine. It's simple and easily readable.
To better explain what I mean by "abstract": if I were to write a payload directly in low-level C or Bash, I would have to carefully calculate every single delay between one command and the next to give the PC time to open windows, and I would have to manually map the hexadecimal codes (HID Keycodes) of every single key to "press". DuckyScript, combined with my parser, automates all of this.

Originally, to use Rubber Ducky scripts, they had to be transformed from simple text files into binary files; this conversion was performed by a PC tool called Ducky Encoder, which converted them into inject.bin. This tool was used because many older devices lacked the computational power to analyze text during runtime, a problem that the ESP32-S3 has now overcome.

So I decided to integrate a native parser into my code: this way, a user can simply upload a file from their phone (via the dedicated internal HTML page) or from a computer and execute it immediately, without having to use an external tool for the conversion. Practically, this is done using standard C functions to separate the actual command from the argument at runtime:

char *cmd = strtok(line, " ");
char *arg = strtok(NULL, "");

if (strcmp(cmd, "DELAY") == 0 && arg) {
    int delay_ms = atoi(arg); 
    if (delay_ms > 0) { 
        vTaskDelay(pdMS_TO_TICKS(delay_ms)); 
    }
}

RAM Security: O(1) Space Complexity

But we all know that C doesn't joke around when it comes to memory allocation, so I tried to make the script reading phase as secure as possible. The underlying problem is that if a user decided to use a very long script (for example, uploading an entire binary file encoded in text), the M5Stick S3 would risk running out of the memory designated for the SRAM, resulting in a Kernel Panic followed by a crash and a device reboot.

To bypass this hardware limit, I thought of allocating a buffer that reads the uploaded file in small, controlled blocks with the help of the fgets() function, which is memory-safe by nature. This mathematically prevents a Buffer Overflow from occurring: even if the user uploads a malicious or malformed file with a single line 10,000 characters long, fgets will still only read the first 255 characters per cycle, safeguarding the microcontroller's stack.

If we look at the reading process from a space-complexity perspective, you can see that the way I decided to implement this mechanic has a space complexity of O(1); whereas the classic implementation would have had a complexity of O(N), as it would have loaded the entire file into RAM simultaneously.

// RAM consumption locked at only 256 bytes
char line[256];

// The file is strictly read and processed line by line
while (fgets(line, sizeof(line), f)) {
    trim_trailing(line); 
    if (strlen(line) == 0) continue;
    
    // ... start parsing for this specific line ...
}

Beyond abstraction: USB Protocol and Polling Rate

Despite all the numerous advantages that come from using the ESP32-S3, one "limit" remains: not being able to use libraries that allow a high level of abstraction, such as Arduino's Keyboard.h. This is a problem because, in the USB standard, a keyboard must regularly build and send 8-byte raw packets (divided into modifier mask, protocol byte, and key array) known as HID Reports.

Sending these reports falls under the polling operation, which is a mechanism by which the Host (the PC) cyclically queries the USB device to check if there have been any state changes. Specifically, I handle these cyclic requests with tud_hid_ready(), which checks if the USB Endpoint is free and if the PC has confirmed the reception of the previous packet. Through the while (!tud_hid_ready()) vTaskDelay(...) block, I prevent the ESP32 from overwriting its own buffer before the packets have actually traveled across the cable. Without this blocking check, the keystrokes would be "dropped" (lost), and a DuckyScript command like STRING powershell would be read by the victim PC as an incomprehensible pwsel.

State-Based Logic and the Auto-Repeat Trap

Added to this strict temporal "dance" of polling is one last huge engineering pitfall related to the nature of 8-byte reports. The most common cognitive error people run into is thinking that USB sends "print commands" (e.g., "type the letter R"). In reality, the USB architecture imposes a State-Based logic: the keyboard only communicates its electromechanical state to the PC at that precise moment.

When we send a report with a specific key, we are not telling it to print it, but we are communicating: "Right now, the user is physically pressing this key".

The operating system's driver receives this state. If the microcontroller were to immediately move to the next command without doing anything else, the PC would think the user's finger was glued to the key, triggering the operating system's Auto-Repeat (which would endlessly open dozens of windows or print RRRRRRRR...). To solve this problem, my firmware is forced to close the cycle by always sending a subsequent "zeroed" HID Report (passing the NULL array to TinyUSB). This tricks the PC, communicating that the key's physical contacts have finally been released (Key Release), allowing us to safely move on to the next letter.

Conclusion

Developing a low-level BadUSB emulator using esp_tinyusb is an immensely more educational challenge compared to using "pre-built" libraries. It forces you to study the anatomy of USB packets, understand how operating systems handle polling, and deal with the physical limits of a microcontroller's memory.

Now our digital "Swiss Army Knife" has its first real weapon, capable of uploading and launching payloads on the fly in total safety.

But a multi-tool isn't just a keyboard. What if we used the ESP32's antenna to intercept the invisible data floating in the air? In the next article, I'll show you how I configured the network interface in promiscuous mode to turn the ESP32 into a Wi-Fi Sniffer, capable of capturing raw packets and saving them directly to the file system in .pcap format, ready to be analyzed on Wireshark.

C++20 Modules in Practice: From Header Hell to Modular Architecture

Tue, 08 Sep 2026 09:53:48 +0000

C++20 Modules replace C++'s traditional textual inclusion model with a compiled module interface. Instead of repeatedly preprocessing the same headers in every translation unit, consumers explicitly import the interface they depend on. No more header guards, no more include-ordering surprises, no more accidentally pulling in transitive dependencies through a chain of #include directives.

But the gap between understanding the idea and actually using modules in a project is significant. Build-system support differs between generators, compilers and standard libraries move at different paces, and partitions have sharp edges that only appear when you build. This post walks through building a small C++ library and application using C++20 Modules, progressively evolving the project to cover the concepts you need in practice.

Everything below was built and run with the toolchain on my machine as of September 2026: GCC 16.2.1, CMake 4.3.0, Ninja 1.13.2 on Linux. Each example that is claimed to work was actually compiled, linked, and executed.

Mental Model: The Key Declarations

Before diving in, here is the vocabulary you will need. Each keyword has a precise meaning, and conflating them is the source of most confusion around modules.

Declaration	What it means	Visible to importers?
`export module math;`	Defines the module interface unit for named module `math`	Yes (exported entities)
`module math;`	Declares this translation unit as a module implementation unit belonging to `math`	No
`import math;`	Imports the named module `math`, making its exported names visible	—
`module;`	Opens the global module fragment (for legacy preprocessing, before the module declaration)	No
`export module math:addition;`	Defines a partition interface unit of `math`	Yes (if re-exported via `export import`)
`module math:addition;`	Defines a partition implementation unit of `math` (name must not duplicate an existing interface partition)	Internal to module only
`import <vector>;`	Imports a header unit (a header compiled as a unit, not a named module)	—

Note especially the difference between two import-sounding declarations: import math; means "make this named module's exports available to me", while module math; means "this translation unit is part of the implementation of module math". They do opposite things, and beginners routinely confuse them.

What a Named Module Actually Is

A named module is a logical entity consisting of one or more module units. Three kinds of units matter for this article:

A module interface unit — a translation unit that begins with export module <name>; and provides the module's exported interface.
A module implementation unit — a translation unit that begins with module <name>;, belongs to the module, but does not itself export anything.
A module partition — a translation unit whose name includes a : (e.g. export module math:addition;); partitions are always part of a named module.

Conflating "a module" with "a .cppm file" is a common mistake. A module is the set of units sharing the module name; the interface unit is just one of them, and the exported names are only the ones marked export.

Unlike a header, a module interface is compiled as a translation unit, and consumers read the compiler's compiled representation of that interface rather than repeatedly preprocessing the same header text.

// math.cppm — module interface unit
export module math;

export int add(int a, int b) {
    return a + b;
}

// main.cpp — consumer translation unit
import math;

int main() {
    return add(1, 2);
}

That is the simplest possible module. Interface in one file, consumer in another, no headers in sight.

Building Modules with CMake and Ninja

There are two important prerequisites before any of this builds:

The generator matters. CMake's C++ module dependency scanning (checking which units produce which interface files, and ordering compilation so interfaces build before their importers) is supported by the Ninja, Ninja Multi-Config, and Visual Studio 17 2022 generators. It is not supported by the Unix Makefiles generator. On Linux, CMake picks Unix Makefiles by default, so you must request Ninja explicitly:
```
cmake -S . -B build -G Ninja
```
Tip for IDE users: If you are using CLion, VS Code with CMake Tools, or another IDE, check your CMake generator settings. Many still default to Unix Makefiles on Linux. Explicitly set -G Ninja in your CMake configuration (e.g., CLion's Toolchains > CMake options, or VS Code's cmake.generator setting) to avoid silent module-scanning failures.
Module interface files must be declared as a CXX_MODULES file set. Declaring math.cppm the way you would list a plain source does not work in modern CMake. I verified this: with CMake 4.3, listing the file directly in add_executable() fails with
```
CMake Error: Output CMakeFiles/app.dir/math.cppm.o provides the `math` module
but it is not found in a `FILE_SET` of type `CXX_MODULES`
```
C++ modules need their own file-set type, which CMake introduced for modules in 3.28:

cmake_minimum_required(VERSION 3.30)
project(MathLib LANGUAGES CXX)

add_executable(app main.cpp)

target_sources(app PRIVATE
    FILE_SET CXX_MODULES
    FILES math.cppm
)

target_compile_features(app PRIVATE cxx_std_20)

cmake -S . -B build -G Ninja
cmake --build build
./build/app

CMake analyzes the module dependency graph and compiles math before main.cpp, even if math.cppm is listed after it in the file set.

A few CMake version notes:

CMake 3.28 introduced both the CXX_MODULES file set and initial experimental module support.
The CMAKE_EXPERIMENTAL_CXX_MODULE_CMAKE_API flag is no longer needed when using the file-set approach on recent toolchains; CMake enables module dependency scanning automatically with a supported generator.
If you are on an older CMake than 3.30, expect version-specific behaviour. Module support has changed in every release since 3.28, and the examples here were tested with CMake 4.3.0.

Interface vs. Implementation Units

A module interface file can contain both declarations and definitions. But in practice, you want to separate them—just like you would with headers and source files.

Consider a math library with an add function:

// math.cppm — interface unit
export module math;

export int add(int a, int b);

// math.cpp — implementation unit
module math;

int add(int a, int b) {
    return a + b;
}

Notice the difference: the interface unit uses export module math;, while the implementation unit uses just module math;. The export keyword on add in the interface makes it visible to consumers. The implementation file provides the body.

The module's exported interface defines what names are intentionally made available. Declarations that are not exported are not reachable by importers through normal means.

Implementation units do not map one-to-one to declarations

An implementation unit does not have to correspond one-to-one with an exported declaration. A single implementation unit can define several exported functions, an exported function can be defined directly in the interface unit, and multiple implementation units can contribute to the same module. The split is an engineering choice, not a language requirement.

For example, everything in the interface:

// math.cppm — everything in the interface unit
export module math;

export int add(int a, int b) {
    return a + b;
}

Or definitions spread across implementation units:

// math.cppm
export module math;

export int add(int a, int b);
export int multiply(int a, int b);

// math.cpp — implementation unit
module math;

int add(int a, int b) {
    return a + b;
}

int multiply(int a, int b) {
    return a * b;
}

Neither form is "more correct". What matters is that the exported names are declared with export in the interface unit.

Splitting Implementation Across Files

As your library grows, you can split implementation code across multiple .cpp files. Each file that begins with module math; is an implementation unit of math, and the compiler and linker combine them.

math-modules/
├── CMakeLists.txt
├── math.cppm
├── math_add.cpp
├── math_multiply.cpp
└── main.cpp

// math.cppm — interface unit
export module math;

export int add(int a, int b);
export int multiply(int a, int b);

// math_add.cpp — implementation unit
module math;

int add(int a, int b) {
    return a + b;
}

// math_multiply.cpp — implementation unit
module math;

int multiply(int a, int b) {
    return a * b;
}

Crucially, implementation units are not module files in the CXX_MODULES sense. They are ordinary sources that happen to declare module math;. I verified that listing math_add.cpp and math_multiply.cpp inside FILE_SET CXX_MODULES fails with:

CMake Error: Output CMakeFiles/app.dir/math_add.cpp.o is of type `CXX_MODULES`
but does not provide a module interface unit or partition

The correct representation:

cmake_minimum_required(VERSION 3.30)
project(MathLib LANGUAGES CXX)

add_executable(app main.cpp)

target_sources(app PRIVATE
    FILE_SET CXX_MODULES
    FILES math.cppm
)
target_sources(app PRIVATE
    math_add.cpp
    math_multiply.cpp
)

target_compile_features(app PRIVATE cxx_std_20)

cmake -S . -B build -G Ninja
cmake --build build
./build/app

All three module units—math.cppm, math_add.cpp, and math_multiply.cpp—belong to the named module math. CMake compiles them separately and links them together.

An incremental rebuild after changing main.cpp recompiles only the consumer and relinks; the module interface is not rebuilt. I verified this with ninja: no work to do on an unchanged tree, and a two-step rebuild after touching main.cpp.

A library, not just an executable

Once you want to share the module, the same structure applies to a library target. Implementation units are plain private sources; the interface file is a public CXX_MODULES file set, which CMake can later install as a compiled module interface:

cmake_minimum_required(VERSION 3.30)
project(MathLib LANGUAGES CXX)

add_library(math
    math_add.cpp
    math_multiply.cpp
)

target_sources(math
    PUBLIC
        FILE_SET CXX_MODULES
        FILES math.cppm
)

target_compile_features(math PUBLIC cxx_std_20)

add_executable(app main.cpp)
target_link_libraries(app PRIVATE math)

Modules and Legacy Headers

Real projects do not start from scratch. You will have existing header-based libraries, system headers, and third-party dependencies. C++20 gives you three distinct ways for a module to interact with legacy textual headers, and it's worth keeping them clearly separated:

#include in the global module fragment — for headers processed before the module purview begins.
#include in the module purview — possible for headers you need to parse, but with real costs.
import of a header unit — a header compiled as a unit rather than textually included.

The common mistake is reaching straight for mechanism 2 because it looks like a plain include.

`#include` in the module purview

A module interface unit can contain #include directives. However, declarations introduced by those headers are not automatically exported merely because they were included. export module strings; followed by #include <string> is not the same as export import <string>;.

// strings.cppm — interface unit
export module strings;

#include <string>

export std::string concatenate(const std::string& a, const std::string& b);

The std::string declarations are needed to parse the exported function signature, but they are not part of the module's exported interface. Yet the header still has an effect: its declarations become part of the module's semantic dependencies, and including large or implementation-oriented headers here increases coupling and complicates portability.

The deeper risk is module attachment. When you #include a header inside the module purview, the declarations from that header become attached to the named module. Entities acquired through module attachment acquire module linkage—they are internal to the module's linkage domain. If another translation unit—outside any named module—also #includes the same header in the traditional way, the same declarations acquire external linkage instead. You now have two different linkage contexts for what looks like the same entity. This can cause subtle One Definition Rule (ODR) violations or symbol conflicts at link time, because the compiler treats the module-attached copy and the traditionally-included copy as distinct. The symptoms range from mysterious linker errors to silent undefined behaviour at runtime.

So: including headers in the module purview is possible, but it is not harmless, and cppreference's guidance is to avoid it in the module interface when you can. Prefer the global module fragment (below) when textual inclusion is genuinely needed.

The global module fragment

The global module fragment exists precisely for the case where textual inclusion is needed. It lets preprocessing directives—especially legacy includes and configuration macros—be processed before the module purview begins.

// legacy_wrapper.cppm
module;

// Processed in the global module, before the module purview.
#include "legacy_header.h"

export module legacy_wrapper;

export void wrapper_function() {
    legacy_function();  // from legacy_header.h
}

The module; declaration at the top opens the global module fragment; everything between module; and export module legacy_wrapper; is processed in the global module. After the export module line, the purview begins.

The standard is strict about what the GMF may contain: only preprocessor directives (#include, #define, #ifdef, etc.). You cannot write raw C++ declarations or definitions inside the GMF—anything that is not a preprocessor directive is ill-formed there. Any declarations you need must come from headers included within the fragment, not from hand-written code.

This is not a bulletproof "safe zone": its purpose is to apply legacy textual inclusion semantics before the module machinery starts. Some legacy headers can still cause problems here. But for headers that need to be textually present—particularly those with configuration macros—the global module fragment is the intended mechanism.

Note the distinction: a regular .cpp source without any module declaration is an ordinary non-module translation unit. It is not a "global module fragment" and does not belong to any named module. The module; declaration must be written explicitly.

Header units

C++20 also defines header units, which allow a header to be imported rather than textually included:

import <vector>;
import "my_legacy_header.h";

Header units behave differently from named modules: they preserve much more of the header's semantics (they are, essentially, the header compiled as a unit), and they are primarily a migration and interoperability mechanism. A header processed as a header unit is not a named module and does not get export semantics. Importing a header unit also requires explicit compiler flags and build-system support to generate a BMI for every header you want to import, which is one reason import std; (C++23) superseded header units for standard-library usage: it provides a single, curated module instead of requiring per-header BMI generation. Support for header units is uneven across compilers, which is why this article focuses on named modules—but you should know the distinction exists, because import alone does not always mean "named module".

Migrating a Header-Based Library

Migrating an existing include/ + src/ library to modules is not a mechanical one-to-one conversion. But the general mapping is:

Traditional	Possible module equivalent
Public header (`include/lib/foo.h`)	Module interface unit (`foo.cppm`)
Source file (`src/foo.cpp`)	Module implementation unit (`foo.cpp`, `module foo;`)
Private header (`include/lib/detail/bar.h`)	Header included by an implementation unit, or a module partition when appropriate
Header-only component	Interface unit, or an interface partition, depending on design

The key insight: headers that were previously available to anyone who included the public header become invisible to importers unless explicitly exported. This is the explicit boundary that modules enforce.

// foo.cppm — the public interface (replaces include/lib/foo.h)
export module foo;

export void public_function();

// foo.cpp — implementation unit (replaces src/foo.cpp)
module foo;

#include "detail/helpers.h"   // private header included here, not exported

void public_function() {
    internal_helper();
}

The private header is included only in the implementation unit. Its contents are not visible to importers of foo.

Partitions

Partitions let you split a module into multiple logical units. There are two kinds, and they serve different purposes:

An interface partition begins with export module math:addition;. It can contain exported declarations, and can be re-exported from the primary module interface with export import :addition;, making its exports visible to consumers of math.
An implementation partition begins with module math:addition;—without the export on the declaration. It cannot export names; it exists only for module-internal organization, often to split a large implementation across files without exposing those boundaries.

The interface-partition arrangement, with definitions written directly in the partition interfaces:

// math.cppm — primary interface
export module math;

export import :addition;
export import :multiplication;

// math.addition.cppm — interface partition
export module math:addition;

export int add(int a, int b) { return a + b; }

// math.multiplication.cppm — interface partition
export module math:multiplication;

export int multiply(int a, int b) { return a * b; }

// main.cpp
import math;

int main() { return multiply(add(1, 2), 3); }

cmake_minimum_required(VERSION 3.30)
project(MathLib LANGUAGES CXX)

add_executable(app main.cpp)

target_sources(app PRIVATE
    FILE_SET CXX_MODULES
    FILES
        math.cppm
        math.addition.cppm
        math.multiplication.cppm
)

target_compile_features(app PRIVATE cxx_std_20)

I compiled and ran this exact arrangement on the toolchain described above; it builds and runs.

A sharp edge: implementation partitions

In C++20, the declaration module math:addition; is ambiguous—it can mean two distinct things:

The implementation unit for an existing interface partition. You have already defined export module math:addition; in a .cppm file, and this .cpp file provides its definitions.
An internal implementation partition. A partition that is not exported to module consumers, but is imported by the primary module (or another partition) via import :addition;. This partition is internal to the module's build, not part of its public interface.

This is not merely a toolchain quirk—it reflects a C++20 standard constraint: partition names must be unique within a named module. A module can have one primary interface unit (export module math;) and multiple primary implementation units (module math;), but each partition name designates a single, distinct translation unit. You cannot have both an interface partition and a separate implementation file sharing the partition name :addition.

In practice, this means math.addition.cppm with export module math:addition; and math.add_impl.cpp with module math:addition; both target the same partition name, and GCC's build model tries to emit a compiled module interface (.gcm / BMI) for both. The BMI output is named after the partition name (math-addition.gcm), not the source file, so the build fails with:

ninja: build stopped: multiple rules generate CMakeFiles/app.dir/math-addition.gcm.

Renaming the files does not help—the collision follows the partition name, not the filename. If you want to separate implementation details into an internal partition, it must use a unique partition name (e.g., module math:addition_impl;), or the definitions should be placed in a standard module implementation unit (module math;). On the toolchain tested here, the standard-constraint collision manifests as a build failure; the language rule is clear, and the build system is correctly enforcing it.

The `std` Module (C++23)

The std module deserves its own section because it combines a genuinely useful idea with a lot of ecosystem caveats.

First, the distinction the article's title implies: modules are C++20, but import std; is C++23. The standard-library module is standardized in C++23 and tracked by the __cpp_lib_modules feature-test macro. A std-module is not the same as the C++20 named-module machinery—it builds on it, but requires a compiler and standard-library implementation that support it.

// main.cpp
import std;

int main() {
    std::vector<int> v = {1, 2, 3};
    std::ranges::sort(v);
    std::cout << v[0] << '\n';
}

import std; can substantially reduce repeated parsing of standard-library headers in some projects, but the actual build-time improvement depends heavily on the compiler, standard library, and project. Do not expect a fixed percentage; measure it on your own tree.

The practical situation deserves precision:

Compilers do not ship import std; as a free lunch. On my machine, GCC's libstdc++ provides bits/std.cc and a libstdc++.modules.json, but import std; still fails out of the box with unknown compiled module interface: no such module until the standard library module has been built and its interface made available.
CMake's support has been experimental throughout the 3.28–4.x era. CMake 3.30 introduced CMAKE_CXX_MODULE_STD and CMAKE_CXX_COMPILER_IMPORT_STD, gated behind experimental import std support; the gating mechanism itself has changed between CMake versions. On CMake 4.3.0 I could not get import std; building out of the box with the straightforward experimental flags.
Support is layered. A compiler may support named modules while its standard library and build system still have incomplete or experimental support for the standard-library module.

The useful practical takeaway: treat import std; as a separate concern from ordinary C++20 named-module support. A toolchain can be fully capable of named modules and still not support import std; yet. Check the documentation for your exact compiler and standard-library versions before relying on it.

For new projects, import std; is worth experimenting with if your toolchain supports it. For existing projects, it can be adopted incrementally, one module at a time.

Compiler, CMake, and IDE Compatibility

There are several separate questions when evaluating module readiness, and a "yes" on one does not imply "yes" on all:

Does the compiler implement C++20 named modules?
Does its standard library work well with modules (and with import std;)?
Does the compiler support the specific module features you want (partitions, header units)?
Does the build system (CMake and the chosen generator) support dependency scanning for your compiler?
Does your IDE's language server understand module imports and rebuild dependencies?

The examples in this article were tested on my machine with the versions shown, using the Ninja generator, with a clean build and an incremental rebuild:

Toolchain	Tested	Basic named modules	Interface partitions	`import std`
GCC + CMake + Ninja	16.2.1 / 4.3.0 / 1.13.2	Yes	Yes	Experimental / not working out of box
Clang + CMake + Ninja	not tested here	—	—	—

Notes on the methodology, so the table means what it appears to mean:

"Basic named modules" = a primary interface unit, a consumer, and—separately—a consumer with implementation units. Both built clean and incrementally.
"Interface partitions" = interface partitions with inline definitions, re-exported via export import from the primary interface. Built clean and incremental.
"Implementation partitions" are not listed as working—they fail due to the partition name uniqueness constraint (see the sharp-edge section above).
import std; is marked experimental: libstdc++ ships the std module source, but it does not build out of the box with the tested CMake version.

Other ecosystem considerations:

IDE support continues to vary. Language servers generally understand named modules now, but completion, navigation, and refactoring across module boundaries may lag behind their header-based equivalents.
Third-party libraries are mostly header-based. Using modules with them requires a wrapper module or the global module fragment.
Package managers are adding module support, but it is not the default.
GCC's own documentation notes that its C++20 module implementation is still incomplete in places. The status improves with every release—check the release notes for your exact version rather than assuming support from the version number.

Modules can be a practical choice for greenfield projects when you control the compiler, standard library, build system, and IDE versions. For large existing codebases, gradual migration is usually more realistic.

What Modules Do Not Solve

Modules are not a universal fix for C++ project complexity. A few things to keep in mind:

Build times can go either way. For small projects, module compilation may be slower than header inclusion because the compiler must first produce a compiled module interface and the build system must manage a dependency graph. The potential benefit comes from avoiding repeated parsing and preprocessing of the same declarations across many translation units; how large the improvement is depends heavily on the dependency graph, compiler, and build structure. Measure it.
Macros are a different story. Macros defined in traditional headers remain governed by the preprocessor and can still pollute any translation unit that includes those headers. In contrast, macros defined inside a named module are not exported to importers. Modules therefore significantly reduce macro leakage from your own module code, but they cannot make legacy headers' macros disappear.
Binary compatibility does not change. Modules affect how you organize source code and what each translation unit sees, not the ABI. Shipping a shared library built with modules looks the same at the binary level as one built with headers.
You still need a build system that understands modules. Modules require the build system to know the dependency graph between interface units, implementation units, partitions, and consumers—a harder problem than the header model, where each translation unit independently resolves its own includes. That is why generator support (Ninja, Visual Studio) and the CXX_MODULES file set matter.

Takeaway

C++20 Modules replace the textual inclusion model with a compiled interface model. The concepts that matter in practice:

An interface unit (export module math;) defines the public API; only exported names are visible to importers.
Implementation units (module math;) provide definitions and internal details; they are ordinary sources, not CXX_MODULES file-set entries.
The global module fragment (module;) handles legacy includes and configuration preprocessing before the module purview.
Legacy headers participate through one of three mechanisms: #include in the global module fragment, #include in the purview, or header-unit import.
Interface partitions (export module math:addition;) organize a module's public interface; implementation partitions (module math:addition;) must use a unique partition name that does not duplicate an existing interface partition—otherwise the build fails due to a C++20 standard constraint.
import std; is C++23, experimental across the ecosystem, and should be evaluated separately from named-module support.

The practical workflow: start with a single .cppm file in a CXX_MODULES file set, put accompanying implementation units in plain sources, use the Ninja generator, and let CMake handle the compilation ordering. Introduce partitions only once the interface genuinely needs them, and test them on your exact toolchain first.

Modules do not solve every problem—macros in legacy headers, binary compatibility, and build tools are still part of the picture. But where you control the toolchain, the explicit boundary between interface and implementation is a real improvement over the header model.

GGUF2BIN Custom C99 runtime: GGUF → G2BX → inference (Qwen3 / Qwen2 / Llama).

Sat, 05 Sep 2026 15:46:48 +0000

gguf2bin2 https://github.com/AnonymoDGH/gguf2bin

English | Español

C99 LLM runtime for low-RAM machines — GGUF → G2BX (own format) → inference.
Weights are memory-mapped: your real RAM budget is KV cache + activations + tokenizer, not the model file.

Runs a 3B model on 145 MB of RAM and a large model on a 2 GB machine (--swap: KV backed on disk, footprint ≈ 37 MB).

⚡ Speed

Measured on Intel i5-6200U · 2C/4T · DDR3L dual-channel (~9.4 GB/s bus ceiling).
Sustained decode with --fast (high priority + OpenMP + quantized KV).

Model	Weights (mmap)	Runtime RAM	decode	prefill
Qwen2.5-3B Q4_0	1992 MB	145 MB	4.3	7.8
Qwen3-0.6B Q4_0	319 MB	511 MB	25.0 / 40.1 (`--mv 0.5`) / 39.2 (`--mv 1.0`)	47.9
LFM2.5-1.2B Q4_0S	567 MB	631 MB	15.7	17.9
Llama-3.2-1B F16	804 MB	644 MB	13.8	—
Llama-3.2-1B Q4_0S_PSY	737 MB	644 MB	14.7 / 30.6 (`--mv 0.5`)	—
SmolLM2-135M Q4_0	72 MB	40 MB	59.5	—

Measured 2026-08-31 on i5-6200U with bench -n 32 (min3). --mv 0.5 Swapeculative + fallback TLS buf → Qwen3 25.0→40.1 tok/s (+60%), Llama Q4_0S_PSY 14.7→30.6 (+108%). --psy (2 scales/256, 132B) gives better ppl than Q4_0S at same speed. At ~25 tok/s decode pinned to DDR3L ~9 GB/s; prefill hits compute ~27 GMAC/s.

🚀 Quick start

make            # Linux / MinGW · OpenMP + AVX2 recommended
make test       # smoke test on a synthetic model

# Pack a GGUF once, run forever
./gguf2bin2 pack Qwen3-0.6B-Q8_0.gguf qwen.g2bx --q4
./gguf2bin2 chat qwen.g2bx --no-think --fast

--threads N picks OpenMP threads; physical cores is the sweet spot.

🧠 RAM knobs

Knob	Effect
`--q8-kv`	KV cache F32→Q8_0: ~3.8× less RAM (94 % greedy argmax agreement)
`-c N`	Context sizes to your session, not the model's 262k max
`--max-ram MB`	Auto: enables Q8 KV first, then halves context until it fits
`--swap [PATH]`	KV cache backed on disk → 37 MB heap even for big models

$ gguf2bin2 run qwen.g2bx "Hello" --max-ram 2048   # ideal for 2 GB machines

What counts against a 2 GB budget?

| Component | Counts? | Fix |
|---|:-:|---|
| Weights (mmap page cache) | ❌ evictable | — |
| KV cache | ✅ | --q8-kv, -c N, --swap |
| Buffers / activations | ✅ small | — |
| Tokenizer (~250k vocab) | ✅ ~30–60 MB | — |

🎛 CLI

gguf2bin2 pack model.gguf out.g2bx [--q4]     # GGUF → G2BX (--q4: half the bytes)
gguf2bin2 info model.g2bx                     # slots, geometry, types
gguf2bin2 run m.g2bx "prompt" [-n N] [-t T] [--bos] [--gpu]
gguf2bin2 chat m.g2bx [--no-think] [--fast] [--swap]
gguf2bin2 bench m.g2bx [-n 32] [--prefill 256]
gguf2bin2 ppl m.g2bx -f text.txt              # quality harness (perplexity)
gguf2bin2 vkinfo                              # Vulkan probe

Sampling: quickselect top-k O(n) + Gumbel-max + xorshift64* reproducible via --seed.

🎮 Dual band CPU+GPU (`--gpu`)

The head GEMV (vocab×dim, the heaviest layer) gets split between CPU and GPU with automatic calibration:

[gpu] worker ready
[gpu] dual band: cpu=[0..44855) gpu=[44855..65536)  tc=6.1ms tg=13.1ms

Vulkan worker in a child process — if the driver crashes or hangs, the runtime falls back to CPU-only without interrupting generation.
Vulkan loader bypass: loads the ICD directly from DriverStore (useful on systems with a broken Khronos\Vulkan\Drivers registry).
Automatic optimal split: gpu = vocab·tc/(tc+tg) measured on the first token; if the GPU is >4× slower than the CPU it shuts itself off.
Supports Q4_0 and Q4_0S heads. Bit-identical output vs the CPU path (greedy).

⚠️ On hardware where the iGPU shares the RAM bus with the CPU (HD 520 + DDR3L) there is no net gain — calibration detects it and disables itself. The real payoff comes with a dGPU with dedicated VRAM.

📐 Quality

Perplexity (internal corpus, SmolLM2-135M-Instruct): uniform Q4_0 = 73.7 (broken),
native Q4_K_M = 48.7, Q6_K = 48.0, Q8_0 = 48.0. Native K-quants keep Q8_0-level
quality within 1.4 % while running faster than uniform Q4_0.

Included numerical validation: make kvtest (F32 vs Q8 KV), tools/prefilltest
(bit-exact batched prefill), tools/qkcheck (46/46 K-quant kernels).

📦 G2BX format & supported types

``` G2BX | ver:u16 | arch:u8 | flags:u8 | ModelCfg | n_slots:u32 | Slot[] | data[] 64B-aligned | tokenizer Slot: role:u8 layer:u16 type:u8 nbytes:u32 off:u64 ``` | Type | Load | Fused matmul | |------|------|--------------| | F32 / F16 | yes (pack→Q4_0 if weight) | F32 path / dequant | | Q4_0 / Q4_1 / Q5_0 | yes | AVX2 fused | | Q8_0 | yes | AVX2 fused | | Q4_0S (own, fp16 shared scale /256) | yes | AVX2 batched | | Q2_K … Q6_K | yes (dequant) | AVX2 fused (Q4_K/Q6_K), scalar rest | | IQ* / Q8_K | partial | — |

🗂 Project layout

``` include/g2b.h common API src/l1_gguf.c GGUF parser (mmap) src/l2_codec.c fused dequant + matmul (AVX2) src/l3_math.c rmsnorm, rope, silu, softmax AVX2 src/l4_gbin.c G2BX packer (generic per-architecture read_cfg) src/l5_model.c load + forward + Q8 KV + RAM budget + GQA-major attention src/l6_token.c BPE tokenizer src/main.c CLI (quickselect/Gumbel sampling, chat with context compaction) src/l7_vulkan.c dual band GPU backend (child-process worker, crash-proof) shaders/ compute shaders (Q4_0/Q4_0S GEMV) tools/ kvtest · prefilltest · exptest · qkcheck · mmbench · dump_gguf.py docs/RESEARCH.md research notes and performance roadmap ```

📜 Changelog

#### v4.7 — Q4_0S_PSY (psicoacústico) + fallback TLS - **Q4_0S_PSY**: 2 escalas fp16 por 256 (132B vs 130B) — baja 128 + alta 128, como MP3. `pack --psy` → +6% speed y mejor ppl que Q4_0S. Llama-3.2-1B 14.7 tok/s (PSY) → 30.6 con `--mv 0.5` (+108%). Fallback IQ ahora TLS buf → qwen38 no hace malloc por fila. #### v4.6 — Swapeculative MV Triple Band - **--mv 0.0..1.0**: tunable skip of FFN (dense) / SSM delta (hybrid) via hash + 2-bit predictor. `25.0 → 40.1 tok/s (+60%)` on Qwen3-0.6B Q4_0 with `--mv 0.5`, `39.2` with `--mv 1.0` on i5-6200U. Quality tradeoff as expected — use 0.3-0.5 for speed, 0 for quality. Works on all archs (Qwen3/Llama/LFM2/Qwen35). #### v4.5 - Batched (prefill) kernel with deferred accumulation: same treatment as the decode kernel. Qwen2.5-3B prefill 4.3 → 7.8 tok/s (+81 %), bit-exact (`tools/prefilltest`). Sets the stage for speculative verification. - **Dual band CPU+GPU head GEMV**: Vulkan worker in a child process (crash-proof), loader bypass loading the ICD straight from DriverStore, automatic split calibration with self-shutdown when the GPU doesn't help. Heads Q4_0/Q4_0S, bit-identical output. #### v4.4 - **--drop N (ShortGPT)**: measures per-block Block Influence during a quick calibration and skips the N least influential blocks. On LFM2.5-1.2B it doesn't pay off (min BI 0.106). #### v4.3 - Decode Q4_0 kernel with deferred accumulation: one hsum per row instead of one per block. Qwen2.5-3B 3.1 → 4.3 tok/s (2.9× vs v3.5); Qwen3-0.6B +10 %. - Q5_0 end-to-end (fused AVX2 kernel with high-bits LUT). - Measured quality table (`ppl` command). #### v4.2 - Fused AVX2 kernels for Q4_K and Q6_K (`maddubs` + m·Σx correction term). Before, any K-quant pack fell to the 2–5× slower fallback. Validated byte-by-byte with `tools/qkcheck`. - `ppl` command; min-of-3 bench (thermal throttling lies). #### v4.1 - K-quants fixed against official ggml (`deq_q3_K/q4_K/q5_K` broken since v3.4: half the tensor unwritten + wrong scale interleave). - Batched prefill (B=8) bit-exact; geometry validation at load; persistent Q8 activation scratch (−210 malloc/free per token). #### v4.0 - Prefill without logits (only the last token computes vocab×dim): prefill 1.32×. - GQA-major attention: each K/V row dequantized once per head group. - softmax/silu AVX2 with fast exp (rel err < 2e-7); rmsnorm fix for non-multiple-of-32 tails. - New sampling: O(n) quickselect top-k, Gumbel-max, xorshift64\*, reproducible `--seed`. - GGUF via mmap; long-chat context compaction. #### v3.x - Q4_0 AVX2 (2 blocks/iter, ILP), AVX2 attention, full K-quant dequant. - Q8_0 KV cache (`--q8-kv`), effective context, RAM budget (`--max-ram`), disk swap. - LLaMA RoPE fix (−2.0/head_dim step) and NEOX vs LLaMA: the historical root of corrupt output.

Was not declared in this scope c++

Wed, 19 Aug 2026 05:46:58 +0000

"was not declared in this scope" is a common error message encountered when programming in C++. This error occurs when a variable or function is used before it has been declared or defined in the current scope. Understanding the scope of variables and functions is crucial for writing correct and efficient C++ code. In this article, we will dive into the world of scope in C++ and explore the different types of scope available, including global, local, function-level, class-level and namespace-level. We will also provide examples and explanations to help you understand the concept better and put it into practice. So whether you're a beginner or an experienced developer, this article will help you master the art of scope in C++.

Understanding scope in C++

In the world of programming, scope is a fundamental concept that every developer must understand. It defines the boundaries of where a variable or function can be used within a program, and can greatly impact the readability and maintainability of your code.

Scope in C++ refers to the region of a program in which a particular variable, function, or object is visible or accessible. In other words, it defines the boundaries of where a variable or function can be used within a program.

There are two types of scope in C++: global and local.

A global variable or function is one that is defined outside of any function or block. It can be accessed from anywhere within the program, including within functions and other blocks. For example:


int x = 5; // global variable

void printX() {
cout

A local variable or function, on the other hand, is one that is defined within a function or block. It can only be accessed within the function or block in which it is defined, and not outside of it. For example:


void printX() {
int x = 5; // local variable
cout

When a local variable and global variable have the same name, the local variable takes precedence within the function or block in which it is defined. For example:


int x = 10; // global variable
void printX() {
int x = 5; // local variable
cout

C++ also has function-level scope, which is similar to local scope, but applies to variables and functions defined within a function. For example:


int main() {
int x = 5; // local variable
{
int x = 10; // nested local variable
cout

In this example, the nested local variable x takes precedence over the outer local variable x within the nested block. Once the block is exited, the outer local variable x becomes visible and accessible again.

Why scope is important? The idea of scope is important because it helps to keep track of variables and functions and ensures that the correct one is being used in the correct context. It also helps to reduce naming conflicts and make the code more readable.

In addition to that, C++ also has class-level and namespace-level scope.
Class-level scope applies to variables and functions defined within a class. They can only be accessed by object of that class or by a friend function/class.
A namespace is a container for a set of identifiers, you can define variables, functions, classes and other types inside a namespace. They can be accessed by using the scope resolution operator (::)

For example:


namespace MyNamespace {
int x = 5;
}

int main() {
cout

It is important to note that, when you define a variable or function with the same name in different namespaces, you can use the scope resolution operator to specify which one you want to use.

Why the error "was not declared in this scope"

When a variable or function is used before it has been declared or defined, the compiler generates an error message indicating that the variable or function "was not declared in this scope". This can happen in several ways:

Using a variable before it has been declared:


#include 

int main() {
std::cout

Using a variable from a different scope:


#include 

int x = 0;

int main() {
{
int x = 1;
std::cout

Using a function before it has been declared or defined:


#include 

int main() {
std::cout

Another common cause of this error is when a variable or function is misspelled. This can happen if the programmer mistypes the name of a variable or function or if the case of the letters is not correct. For example, if a variable is declared as myVariable but is later referred to as myvariable, this will result in a "was not declared in this scope" error.


#include 

int main() {
int myVariable;

std::cout

How to fix the error

To fix this error, we need to ensure that the variable or function is declared or defined before it is used. This can be done by:

Declaring the variable before it is used:


#include 

int main() {
int x;
std::cout

Using the variable or function from the correct scope:


#include 

int x = 0;

int main() {
{
int x = 1;
std::cout

Declaring the function before it is used:


#include 

int foo(){return 1;}

int main() {
std::cout

Tip It is important to keep in mind that variables have a scope and that scope determines where the variable can be accessed from. Also, function should be declared before they are called. The error message "was not declared in this scope" is a reminder of these important concepts in C++ programming.

Conclusion

In conclusion, "was not declared in this scope" error can occur due to a variety of reasons such as variable or function being used before it has been declared or defined, it being in the wrong scope or not being spelled correctly. It is important to pay attention to the variables and functions that are being used in the code, and to make sure that they have been declared and defined before they are used.

References

Stroustrup, B. (2013). The C++ Programming Language (4th ed.). Addison-Wesley Professional.
Deitel, P. J., & Deitel, H. M. (2015). C++ How to Program (10th ed.). Pearson Education.
Lippman, S. B., Lajoie, J., & Moo, B. E. (2012). C++ Primer (5th ed.). Addison-Wesley Professional.

Build a Dynamic Array in C from Scratch

Fri, 31 Jul 2026 10:38:49 +0000

Build a Dynamic Array in C from Scratch

You've used push() in JavaScript, append() in Python, add() in Java. They feel instant. They never run out of space. You never think about them.

That's a problem — not because those abstractions are bad, but because you're using a tool without knowing what it costs. Every one of those methods is built on ideas you can understand completely. This article will show you how, in C, where the machine hides nothing from you.

By the end you'll have built a working dynamic array and, more importantly, a mental model that makes std::vector, Go slices, and Rust's Vec all obvious.

The Core Idea: Two Layers of Memory

Before writing a single line, you need to understand the central insight that makes a dynamic array possible.

A normal array is a fixed block of memory. You declare int numbers[8] and the compiler carves out exactly 32 bytes on the stack. That's it. If you need a 9th element, you're stuck.

A dynamic array gets around this by living on the heap — a region of memory that your program can request and release at runtime, in any size, at any time. The heap doesn't get freed automatically when a function returns. You control it. That control is what makes resizing possible, and what makes memory bugs possible too.

The dynamic array is two things at once: a block of integers sitting somewhere on the heap, and a small control structure that remembers where that block is, how big it is, and how many elements are currently in it. Everything we build is just bookkeeping those two things correctly.

What You Need to Know First

Memory: Stack vs Heap

When you declare a local variable, it goes on the stack. The stack is fast and automatic — variables appear when a function is called and vanish when it returns.

void foo() {
    int x = 10; // lives on the stack
}               // x is gone here

The heap is different. Memory there persists until you explicitly free it. You ask the OS for a chunk, use it, and free it when you're done. This is what enables data structures that outlive the function that created them.

Pointers

A pointer is a variable that holds a memory address rather than a value.

int score = 99;
int *ptr = &score; // ptr holds the address of score, not 99

&score means "give me the address of score." *ptr means "go to that address and read what's there." They're inverse operations.

Why does this matter? Because when you allocate memory on the heap, you get back an address — a pointer — to where that memory starts. There's no other way to refer to heap memory. Pointers aren't a language quirk; they're the only handle you have on dynamic allocation.

int *numbers = malloc(sizeof(int) * 8);
// numbers holds the address of a 32-byte block on the heap
// numbers[0], numbers[1], ... numbers[7] are all valid

malloc returns a pointer to the allocated block. sizeof(int) gives the size in bytes of one integer (typically 4). Multiply by 8 and you get 32 bytes — room for 8 integers.

Structs

C has no classes. To group related data, you use a struct.

struct IntArray {
    int *data;     // pointer to the integers on the heap
    int length;    // how many elements are currently stored
    int capacity;  // how much space is allocated
};

typedef lets you drop the struct keyword every time you use it:

typedef struct {
    int *data;
    int length;
    int capacity;
} IntArray;

Now IntArray arr; is valid instead of struct IntArray arr;. Small thing, but it adds up.

The -> operator accesses a struct's field through a pointer:

array->length  // same as (*array).length

You'll use -> constantly because our functions always receive a pointer to the struct, not the struct itself. Passing the struct by value would copy all three fields every time — wasteful, and it means modifications wouldn't be visible to the caller.

The Header Files

#include <stdio.h>   // printf, scanf
#include <stdlib.h>  // malloc, realloc, free, exit
#include <stdbool.h> // bool, true, false

stdlib.h is the critical one. Every memory function we use lives there. Without it, malloc and free are undeclared.

stdbool.h exists because C didn't originally have a boolean type. It gives you bool, true, and false as proper names instead of int, 1, and 0.

The Structure

Now that the building blocks are clear, the struct makes obvious sense:

#define DEFAULT_CAPACITY 8

typedef struct {
    int *data;     // address of our integer block on the heap
    int length;    // elements currently stored (logical size)
    int capacity;  // elements we have room for (physical size)
} IntArray;

length and capacity are not the same thing. This distinction is the heart of how a dynamic array works.

capacity = 8  (8 slots exist in memory)
length   = 3  (only 3 are in use)

[ 10 | 20 | 30 | __ | __ | __ | __ | __ ]
  [0]  [1]  [2]

When length == capacity, the array is full and must grow before the next add.

#define DEFAULT_CAPACITY 8 is a compile-time constant. The preprocessor replaces every occurrence of DEFAULT_CAPACITY with 8 before the compiler sees the code. It's not a variable — it has no address and uses no runtime memory.

Creating the Array

IntArray *createArray(int capacity) {

    // Guard against nonsense input
    if (capacity <= 0)
        capacity = DEFAULT_CAPACITY;

    // Allocate the control struct on the heap
    // This gives us room for: one pointer, two ints
    IntArray *array = malloc(sizeof(IntArray));

    if (array == NULL) {
        printf("Memory allocation failed\n");
        exit(EXIT_FAILURE); // no safe way to recover here
    }

    // Allocate the integer block separately
    // The struct just holds a pointer to this block
    array->data = malloc(sizeof(int) * capacity);

    if (array->data == NULL) {
        printf("Memory allocation failed\n");
        free(array); // don't leak the struct we just allocated
        exit(EXIT_FAILURE);
    }

    array->length = 0;        // no elements yet
    array->capacity = capacity; // but we have space reserved

    return array; // return the address of the struct
}

Notice we allocate twice. Once for the struct, and once for the integer data. These are two separate heap allocations, and that's why we must free both when we're done. The struct contains the address of the data block, but it doesn't own it in any automatic sense — we have to track and free it ourselves.

The return type is IntArray * — a pointer. We're not returning the struct itself; we're returning its address. This is the handle the caller will use for every subsequent operation.

Destroying the Array

void destroyArray(IntArray *array) {
    free(array->data); // free the integer block first
    free(array);       // then free the struct
}

Order matters. Free the data block first, then the struct. If you freed the struct first, array->data would be a dangling read — you'd be accessing memory through a pointer to something that's already freed.

Every malloc must have exactly one matching free. This is the discipline C demands. Modern languages have garbage collectors to enforce this automatically. In C, it's on you.

Getting and Setting Elements

int get(IntArray *array, int index) {
    if (index < 0 || index >= array->length) {
        printf("Index out of bounds\n");
        exit(EXIT_FAILURE);
    }
    return array->data[index];
}

void set(IntArray *array, int index, int value) {
    if (index < 0 || index >= array->length) {
        printf("Index out of bounds\n");
        exit(EXIT_FAILURE);
    }
    array->data[index] = value;
}

The bounds check is not optional. Without it, array->data[index] when index >= length reads memory that belongs to something else — possibly another variable, possibly the OS. C won't stop you. The behavior is undefined, which in practice means silent data corruption or a crash that's hard to trace.

Both operations are O(1) because array->data[index] computes directly to a memory address:

address = base_address + (index × sizeof(int))

No searching. One arithmetic operation.

Adding Elements: The Core of a Dynamic Array

This is the function everything else builds toward.

void add(IntArray *array, int value) {

    // Is the array full?
    if (array->length == array->capacity) {

        // Double the capacity — we'll explain why below
        array->capacity *= 2;

        // Ask the OS to resize our integer block
        int *newData = realloc(
            array->data,
            sizeof(int) * array->capacity
        );

        // CRITICAL: store in a temp pointer, not array->data
        // If realloc fails, it returns NULL — if we assigned
        // directly to array->data we'd lose the original pointer
        // and have a memory leak with no way to recover
        if (newData == NULL) {
            printf("Reallocation failed\n");
            exit(EXIT_FAILURE);
        }

        // Only update once we know it succeeded
        array->data = newData;
    }

    // Store the value and advance the length in one step
    array->data[array->length++] = value;
}

realloc is malloc's smarter sibling. It takes an existing pointer and a new size. If it can extend the block in place, it does. If not, it allocates a new block, copies the old data, frees the old block, and returns the new address. The existing contents are preserved either way.

Why double the capacity instead of growing by 1?

If you grew by 1 every time the array filled up, every single add would trigger a realloc and a copy of all existing elements. Adding n elements would cost O(n²) total.

Doubling means resizes happen at sizes 4, 8, 16, 32, 64... Each resize copies everything, but the number of copies per element approaches 2 as n grows. Over many insertions, the average cost per add is O(1). This is called amortized constant time — expensive occasionally, cheap on average.

Removing Elements

Remove by Index

void removeAt(IntArray *array, int index) {

    if (index < 0 || index >= array->length) {
        printf("Index out of bounds\n");
        exit(EXIT_FAILURE);
    }

    // Shift every element after the removed one left by one position
    for (int i = index; i < array->length - 1; i++) {
        array->data[i] = array->data[i + 1];
    }

    // The last position still holds the old value, but we don't
    // erase it — we just stop counting it as part of the array
    array->length--;
}

The loop goes to array->length - 1, not array->length. At the final iteration, i is length - 2 and we read array->data[length - 1]. If the loop ran to length, the last iteration would read array->data[length], which is outside the allocated block.

This is O(n) in the worst case — removing from index 0 shifts every element.

Remove by Value

bool removeValue(IntArray *array, int value) {
    for (int i = 0; i < array->length; i++) {
        if (array->data[i] == value) {
            removeAt(array, i);
            return true;  // remove first match only
        }
    }
    return false; // value wasn't in the array
}

Search linearly, delegate the actual removal to removeAt. Returns false when the value isn't found so the caller can detect the miss.

Reversing the Array

void reverse(IntArray *array) {
    int left = 0;
    int right = array->length - 1;

    while (left < right) {
        // Swap elements at left and right
        int temp = array->data[left];
        array->data[left] = array->data[right];
        array->data[right] = temp;

        // Move both pointers inward
        left++;
        right--;
    }
}

The two-pointer technique. Start from opposite ends, swap, move inward, stop when they meet. O(n) time, O(1) extra space — no second array needed.

The condition is left < right, not left != right. For an odd-length array, they'll converge on the middle element. That element doesn't need swapping with itself, so the loop correctly stops before touching it.

Printing

void printArray(IntArray *array) {
    printf("[");
    for (int i = 0; i < array->length; i++) {
        printf("%d", array->data[i]);
        if (i != array->length - 1)
            printf(", ");
    }
    printf("]\n");
}

The comma logic — print a comma after every element except the last — is a common pattern. The alternative (printing a comma before every element except the first) is equivalent; pick one and be consistent.

Putting It Together

int main() {
    IntArray *arr = createArray(4); // capacity 4, length 0

    add(arr, 3);   // length 1
    add(arr, 7);   // length 2
    add(arr, 6);   // length 3
    add(arr, -2);  // length 4, capacity 4 — full

    printArray(arr); // [3, 7, 6, -2]

    removeValue(arr, 7); // shift left, length becomes 3

    printArray(arr); // [3, 6, -2]

    reverse(arr); // two-pointer swap

    printArray(arr); // [-2, 6, 3]

    destroyArray(arr); // free data block, then free struct

    return 0;
}

Note: the first add after createArray(4) that would require a 5th slot would trigger a resize — capacity doubles to 8. In this main we add exactly 4 elements, so no resize occurs. To see it in action, add a 5th element.

The Gotchas

Assigning realloc directly to the original pointer.

// Wrong — if realloc returns NULL, you've lost your data
array->data = realloc(array->data, newSize);

// Right — check before assigning
int *newData = realloc(array->data, newSize);
if (newData != NULL) array->data = newData;

Freeing in the wrong order.
Free array->data before array. If you free the struct first, you're reading array->data through a dangling pointer.

Using length instead of capacity in the resize check.
The array is full when length == capacity. If you compare against the wrong field, you either resize too early (wasted allocations) or never resize at all (out-of-bounds writes).

Off-by-one in removeAt's loop.
The loop runs to array->length - 1, not array->length. The last iteration reads data[length - 1]. Going one further reads past the end of the allocated block.

Not checking malloc for NULL.
malloc returns NULL when the OS can't satisfy the request. Dereferencing a NULL pointer is undefined behavior. Always check.

Using the array after destroyArray.
After you free memory, the pointer still holds the old address. Reading through it is undefined behavior. Set pointers to NULL after freeing if you need to guard against accidental reuse.

Junior Pattern vs Senior Pattern

Resizing:

// Junior — assigns directly, leaks memory on failure
array->data = realloc(array->data, sizeof(int) * array->capacity);
if (array->data == NULL) exit(EXIT_FAILURE); // original pointer is gone

// Senior — uses temp, original is recoverable on failure
int *newData = realloc(array->data, sizeof(int) * array->capacity);
if (newData == NULL) {
    // array->data is still valid here, nothing was lost
    exit(EXIT_FAILURE);
}
array->data = newData;

Cleanup:

// Junior — frees struct first, then reads dangling pointer
free(array);
free(array->data); // undefined behavior: array is already freed

// Senior — free data first, then the container
free(array->data);
free(array);

Bounds checking:

// Junior — trusts the caller
return array->data[index];

// Senior — validates before accessing
if (index < 0 || index >= array->length) {
    // handle error
}
return array->data[index];

Where This Lives in the Real World

std::vector in C++ is this exact structure. The underlying implementation uses new[] instead of malloc, but the capacity/length distinction, the doubling strategy, and the contiguous memory layout are identical.

Go slices have a header with ptr, len, and cap — those are our data, length, and capacity. When you append past cap, Go allocates a new backing array, copies, and returns a new slice header.

Rust's Vec<T> is the same: a heap-allocated contiguous buffer, a length, and a capacity. The ownership system handles the freeing automatically, but the memory layout underneath is what you just built.

Time Complexity

Operation	Complexity	Why
`get`	O(1)	Direct address calculation
`set`	O(1)	Direct address calculation
`add` (no resize)	O(1)	Write to `data[length]`, increment
`add` (resize)	O(n)	`realloc` copies all elements
`add` (amortized)	O(1)	Resizes are infrequent enough
`removeAt`	O(n)	Shift all elements after index
`removeValue`	O(n)	Linear scan + shift
`reverse`	O(n)	Visit each element once

Your Turn

Extend the implementation with these two functions:

// Insert a value at a specific index, shifting everything right
void insertAt(IntArray *array, int index, int value);

// Return the index of the first occurrence of value, or -1 if not found
int indexOf(IntArray *array, int value);

Constraints: insertAt must handle growth the same way add does. indexOf must return -1, not exit, when the value is absent.

You'll know you're done when this main produces the expected output:

IntArray *arr = createArray(4);
add(arr, 10);
add(arr, 30);
insertAt(arr, 1, 20); // insert 20 between 10 and 30
printArray(arr);      // [10, 20, 30]
printf("%d\n", indexOf(arr, 20)); // 1
printf("%d\n", indexOf(arr, 99)); // -1
destroyArray(arr);

Introducing Algenix: Building an Open-Source Computer Algebra System from Scratch in Modern C++

Fri, 24 Jul 2026 14:33:53 +0000

🚀 Introducing Algenix: Building an Open-Source Computer Algebra System from Scratch

A modern symbolic mathematics engine built from scratch with a high-performance C++ core and a clean Python API.

🌟 The Beginning

Every developer has a dream project.

Some build game engines.
Some build operating systems.
Some build programming languages.

My dream is to build Algenix — a modern, open-source Computer Algebra System (CAS) developed completely from scratch.

Algenix is not intended to be just another mathematics library. My goal is to create a complete symbolic mathematics engine capable of understanding, manipulating, and solving mathematics in a way that is powerful, extensible, and easy to use.

🤔 Why Build Algenix?

Mathematics is at the heart of engineering, robotics, physics, artificial intelligence, computer graphics, and scientific computing.

While there are already established symbolic mathematics libraries, I wanted to explore the challenge of designing and implementing my own symbolic engine and architecture.

Building a CAS involves many fascinating areas of computer science, including:

Mathematical parsing
Compiler-like tokenization and lexing
Expression trees (ASTs)
Symbolic algebra
Equation solving
Formula simplification
Polynomial manipulation
Exact arithmetic
Algorithm design
Performance optimization

Rather than relying on an existing symbolic engine, Algenix is planned as a fresh implementation with its own design.

🎯 The Vision

Algenix aims to become a modern mathematics platform featuring:

⚡ High-performance C++ core
🐍 Clean Python bindings
🌍 Cross-platform support
📖 Extensive documentation
🧪 Comprehensive testing
💻 Interactive command-line interface
🧮 Natural mathematical syntax
📦 Easy installation via pip

One of the long-term goals is to allow mathematical expressions to be written naturally.

For example:

2x + 5 = 17

instead of requiring programming-style syntax.

🧠 Planned Features

The roadmap is divided into major releases, with each version introducing a new area of mathematics.

Some planned capabilities include:

Core Algebra

Expression simplification
Expansion
Factorization
Polynomial operations
Collecting like terms
Symbolic substitution

Equation Solving

Linear equations
Quadratic equations
Simultaneous equations
Integer solution generation
Constraint-based solving
Step-by-step solutions

Symbolic Mathematics

Symbolic variables
Exact fractions
Radical expressions
Expression rewriting
Formula manipulation

Calculus

Limits
Derivatives
Integrals
Taylor series
Differential equations

Linear Algebra

Matrices
Determinants
Eigenvalues
Eigenvectors
Matrix decompositions

Geometry

Coordinate geometry
2D and 3D geometry
Transformations
Distance calculations

Statistics & Probability

Mean
Median
Variance
Probability
Regression

Number Theory

Prime numbers
Modular arithmetic
Diophantine equations
Number properties

Developer Features

Python API
C++ API
Command-line interface
Plugin support
Project file format
Extensive examples

📈 A Long-Term Roadmap

Rather than trying to build everything in a single release, Algenix will grow through carefully planned versions.

Each version will focus on a specific mathematical domain while keeping the project stable and maintainable.

This approach allows the project to improve continuously while providing useful releases along the way.

📚 Designed for Everyone

Algenix is intended for:

👨🎓 Students
👩🏫 Teachers
👨💻 Developers
🤖 Robotics enthusiasts
🔬 Researchers
⚙️ Engineers
📊 Scientific programmers

Whether you're solving equations, experimenting with symbolic algebra, or building mathematical software, the goal is to make Algenix a useful tool.

❤️ Open Source from Day One

Algenix is planned as an open-source project.

The repository will include:

Complete source code
Extensive documentation
Example programs
Unit tests
Continuous Integration
Version history
Roadmaps
Contribution guides

The project will evolve publicly, allowing others to follow its progress and contribute ideas.

🚀 Looking Ahead

Building a Computer Algebra System from scratch is a significant challenge, but it's also an opportunity to learn more about mathematics, algorithms, parsing, language design, and software engineering.

Algenix is a long-term project, and every version will represent another step toward a complete symbolic mathematics platform.

I hope developers, students, and mathematics enthusiasts will find the journey interesting.

Thank you for reading, and stay tuned for the first release of Algenix.

Sequence contains no elements

Thu, 02 Jul 2026 06:40:00 +0000

Today, we're going to fix a LINQ Error: Sequence contains no elements which the programmers encounter in daily life. It usually happens when we're using the Single() or First() method to retrieve a value from a dataset. In this study blog, we'll explore why it happens and how to resolve it.

What is "Sequence contains no elements" #

This error happens we use Single() or First() to retrieve a value but the value doesn't exist in the dataset. Let's look an example:


internal class Student
    {
        private string name;
        private int age;
        private string gender;
        private string hobby;

        public Student(string name, int age, string gender, string hobby)
        {
            this.name = name;
            this.age = age;
            this.gender = gender;
            this.hobby = hobby;
        }

        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        public int Age
        {
            get { return age; }
            set { age = value; }
        }
        public string Gender
        {
            get { return gender; }
            set { gender = value; }
        }
        public string Hobby
        {
            get { return hobby; }
            set { hobby = value; }
        }
    }

First, I create a Student class with some properties.


List students = new List()
{
      new Student("Alex", 22, "Male", "Basketball"),
      new Student("Cindy", 20, "Female", "Badminton"),
      new Student("Joshua", 20, "Male", "Swimming"),
      new Student("Emily", 21, "Female", "Basketball"),
      new Student("Josely", 22, "Female", "Jogging"),
};

var result = students.Where(student => student.Name == "Alex").Single();
Console.WriteLine($"Here is the result:\n {Newtonsoft.Json.JsonConvert.SerializeObject(result)}");

Then, I create a list of Student objects in my program.cs and use the Single() to get the only Student with name Alex.

Note We need to install Newtonsoft library in the Nuget Package so that we can use it to print out the JSON string of our Student object result.

This is the result:


Here is the result:
 {"Name":"Alex","Age":22,"Gender":"Male","Hobby":"Basketball"}

Look, now we didn't get any errow because there's one Student with name Alex. Let's see another example:


List students = new List()
{
      new Student("Alex", 22, "Male", "Basketball"),
      new Student("Cindy", 20, "Female", "Badminton"),
      new Student("Joshua", 20, "Male", "Swimming"),
      new Student("Emily", 21, "Female", "Basketball"),
      new Student("Josely", 22, "Female", "Jogging"),
};

var result = students.Where(student => student.Name == "Clarence").Single();
Console.WriteLine($"Here is the result:\n {Newtonsoft.Json.JsonConvert.SerializeObject(result)}");

This is the result:


System.InvalidOperationException: 'Sequence contains no elements'

Now, the Sequence contains no elements error occurs. Let's look at another example using First() method:


List students = new List()
{
      new Student("Alex", 22, "Male", "Basketball"),
      new Student("Cindy", 20, "Female", "Badminton"),
      new Student("Joshua", 20, "Male", "Swimming"),
      new Student("Emily", 21, "Female", "Basketball"),
      new Student("Josely", 22, "Female", "Jogging"),
};

var result = students.Where(student => student.Name == "Clarence").First();
Console.WriteLine($"Here is the result:\n {Newtonsoft.Json.JsonConvert.SerializeObject(result)}");

This is the result:


System.InvalidOperationException: 'Sequence contains no elements'

Same error occurs. Why? we'll see that next.

Causes #

Let's see the different types of errors that will be thrown while using Single() or First() method:

Single():

ArgumentNullException: Thrown when the source sequence is null.
InvalidOperationException: Thrown when the no element satisfies the condition OR more than one element satisfies the condition OR the source sequence is empty.

First():

ArgumentNullException: Thrown when the source sequence is null.
InvalidOperationException: Thrown when no element satisfies the condition OR the source sequence is empty.

According to the example on previous section, both Single() and First() method are getting the same error, that's System.InvalidOperationException: 'Sequence contains no elements'. This is because both of them can't find a value that meets the condition stated in the statement! So, how can we allow our program to run while this error is catched without being thrown at the output? Let's go to the next section.

Solution #

The solution is pretty simple, that's: instead of Single() or First(), use SingleOrDefault() or FirstOrDefault(). Instead of throwing the error "Sequence contains no elements", they will return a null value if no result found. Let's say:


List students = new List()
{
      new Student("Alex", 22, "Male", "Basketball"),
      new Student("Cindy", 20, "Female", "Badminton"),
      new Student("Joshua", 20, "Male", "Swimming"),
      new Student("Emily", 21, "Female", "Basketball"),
      new Student("Josely", 22, "Female", "Jogging"),
};

var result = students.Where(student => student.Name == "Clarence").SingleOrDefault();
Console.WriteLine($"Here is the result:\n {Newtonsoft.Json.JsonConvert.SerializeObject(result)}");

This is the result:


Here is the result:
 null

and for FirstOrDefault():


List students = new List()
{
      new Student("Alex", 22, "Male", "Basketball"),
      new Student("Cindy", 20, "Female", "Badminton"),
      new Student("Joshua", 20, "Male", "Swimming"),
      new Student("Emily", 21, "Female", "Basketball"),
      new Student("Josely", 22, "Female", "Jogging"),
};

var result = students.Where(student => student.Name == "Clarence").FirstOrDefault();
Console.WriteLine($"Here is the result:\n {Newtonsoft.Json.JsonConvert.SerializeObject(result)}");

This is the result:


Here is the result:
 null

Now, we can run our program without the error: Sequence contains no elements in the output. Although the condition is not met, we still can get a default object, which is null. Looks, the solution is pretty simple right?

Tip You can also execute some codes based on the object returned or return NotFound() if you're using ControllerBase.

For instance:


List students = new List()
{
      new Student("Alex", 22, "Male", "Basketball"),
      new Student("Cindy", 20, "Female", "Badminton"),
      new Student("Joshua", 20, "Male", "Swimming"),
      new Student("Emily", 21, "Female", "Basketball"),
      new Student("Josely", 22, "Female", "Jogging"),
};

var result = students.Where(student => student.Name == "Clarence").FirstOrDefault();
if(result != null)
{
    Console.WriteLine($"Here is the result:\n {Newtonsoft.Json.JsonConvert.SerializeObject(result)}");
}
else
{
    Console.WriteLine("The student is not found in the record!");
}

This is the result:


The student is not found in the record!

The Conclusion #

In this study blog, we've learned what is Sequence contains no elements in LINQ, why it happens and how to resolve it. Note that using SingleOrDefault() or FirstOrDefault() is always better as they will not throw exception and terminate the program. Instead, they can help the programmers to check the output while executing the statement. Thank you and enjoy your day! :)

The Reference #

For further information, please visit:

Serialization: https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/serialization/
Single() in LINQ: https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.single?view=net-7.0
First() in LINQ: https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.first?view=net-7.0
SingleOrDefault() in LINQ: https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.singleordefault?view=net-7.0
FirstOrDefault() in LINQ: https://learn.microsoft.com/en-us/dotnet/api/system.linq.enumerable.firstordefault?view=net-7.0

Convert the string into Camel case and remove special characters from string in C, C++

Mon, 25 May 2026 04:00:43 +0000

You might have encountered situation that's required to Convert the string into Camel case and remove special characters from string in C or C++. To solve this problem, we can simply converting the string to camel case, then eliminating all special characters. In this article, we will also go over details with examples.

Identify the problem
Solution
1. Solution in C++
2. Solution in C
Conclusion
Reference

1. Identify the problem#

An usual string, such as this sentence "Hello World! How are you today?", is not only contain word seperated by space. It's also has some special characters like the question mark '?' or the exclamation mark '!'. We only need the words and digits to remain, and erase the rest.

Input

How old are you? I'm 15 years old

Output

HowOldAreYouIm15YearsOld

2. Solution #

Take the first example:

Hello World! How are you today?

It'll be easier to consider this problem as 2 smaller sub-problem: Converting a string to camel case, and removing all special characters from a string. We will go into the details of the solution with both C and C++, as well as things to keep in mind for each method.

1. Solution in C++

We first create a function 'toCamelCase(string str)' which takes a string as an input and converts it to camel case.


void to_camel_case(std::string &s) {
  if (s.empty()) return;
  for (int i = 0; i < s.length(); i++) {
    if (s[i] == ' ' || s[i] == '_') {
      int j = i + 1;
      if (j < s.length()) {
        s[j] = toupper(s[j]);
      }
    }
  }
}

Then, we design a function called 'removeSpecialChars(string str)' to return the input string after removing all special characters.


void remove_special_characters(std::string &s) {
  if (s.empty()) return;
  for (int i = 0; i < s.length(); i++) {
    if (!isalnum(s[i])) {
      s.erase(i, 1);
      i--;
    }
  }
}

2. Solution in C

There seemes no obvious different when comparing to the solution in C++. First we convert string to camel case, then remove special characters.


void to_camel_case(char *s) {
  if (s == NULL) return;
  int len = strlen(s);
  if (len == 0) return;
  for (int i = 0; i < len; i++) {
    if (s[i] == ' ' || s[i] == '_') {
      int j = i + 1;
      if (j < len) {
        s[j] = toupper(s[j]);
      }
    }
  }
}


void remove_special_characters(char *s) {
  if (s == NULL) return;
  int len = strlen(s);
  if (len == 0) return;
  for (int i = 0; i < len; i++) {
    if (!isalnum(s[i])) {
      for (int j = i; j < len; j++) {
        s[j] = s[j + 1];
      }
      len--;
      i--;
    }
  }
}

But we need to pay attention to the type of string in C.

Caution In C++, we use the std::string class to handle strings, which provides a lot of helpful methods for manipulating strings, such as erase and empty. In C, we have to use arrays of characters, and manually manage memory allocation and deallocation.

The C++ implementation provides a more convenient and easier-to-use interface for string manipulation, while the C implementation provides a lower-level interface that gives you more control over memory and performance.

Finally, after execute 2 functions, we will be able to receive the desired result

Output

HelloWorldHowAreYouToday

3. Conclusion#

Going through this article, we've discussed about how to Convert the string into Camel case and remove special characters from string in C and C++ , by raising the first letters from each word to uppercase first, after that removing the special characters. I recommend reading in details to understand better how it works and knows the different between 2 cases. Have a nice day!

4. Reference#

For further information, please visit:

toupper(): cplusplus.com/reference/cctype/toupper
string: https://devdocs.io/c/string/byte

Index was outside the bounds of the array

Thu, 21 May 2026 12:28:19 +0000

Today, we're going to fix a C# Error: Index was outside the bounds of the array that usually occurs when we try to access the index less than 0 or greater than or equal to the array length - 1. In this study blog, we'll explore why it happens and how to resolve it.

What is "Index was outside the bounds of the array" #

This error happens when we try to access the elements in the array using invalid index. Let's see an example:


int[] numbers = new int[] { 1,2,3,4,5,6,7,8,9 };
for(int i = 0; i <= numbers.Length; i++)
{
    Console.WriteLine(numbers[i]);
}
  </span>

This is the output:


1
2
3
4
5
6
7
8
9
System.IndexOutOfRangeException: 'Index was outside the bounds of the array.'

Why? Because the numbers array has 9 elements, and thus its length is 9. However, in programming, each collection like array has indices in the range of [0 - N-1], where N = array.length and we can access each element in the array within that range. In the above example, after accessing index 8 with element 9 in numbers array, we tend to access element at index 9, which is an invalid index for numbers array. That's why this error occur.

Let's look at another example:


int[] numbers = new int[] { 1,2,3,4,5,6,7,8,9 };
numbers[-1] = 10;

This is the output:


System.IndexOutOfRangeException: 'Index was outside the bounds of the array.'

Why? we're trying to assign value to the element of numbers array at index -1, which is also an invalid index for numbers array. Hence, the error will also occur.

Causes #

The error, Index was outside the bounds of the array is actually under IndexOutOfRangeException Class in C#. IndexOutOfRangeException: The exception is thrown when the attempt to access the element of a collection or an array using the index outside its bounds is made. Hence, System.IndexOutOfRangeException: 'Index was outside the bounds of the array.' occurs when we're trying to access the element of an array using invalid index. Don't fret; it can be simply resolved.

Note Every collection such as list, array or the other has only indices in the range of [0, N-1], where N is the length of the array itself.

Solution #

The solution is pretty simple, we just need to ensure we're accessing the elements of the array using the indices within its bounds. Let's say:


int[] numbers = new int[] { 1,2,3,4,5,6,7,8,9 };
for(int i = 0; i < numbers.Length; i++)
{
    Console.WriteLine(numbers[i]);
}

This is the output:

or you may also do like this:


int[] numbers = new int[] { 1,2,3,4,5,6,7,8,9 };
for(int i = 0; i <= numbers.Length-1; i++)
{
    Console.WriteLine(numbers[i]);
}
  </span>

This is the output:

Both examples above are having the same output. What we do is to ensure that the iteration will only be in the range of [0 - N-1], where N = array.length. The numbers array has the length of 9, and thus can only iterate from 0 to 8. These are the valid indices for the numbers array.

Tip You may also use GetLowerBound(Int32) and GetUpperBound(Int32) to avoid this error.


int[] numbers = new int[] { 1,2,3,4,5,6,7,8,9 };
for(int i = numbers.GetLowerBound(0); i <= numbers.GetUpperBound(0); i++)
{
    Console.WriteLine(numbers[i]);
}
  </span>

This is the output:

For the case above, GetLowerBound(0) is used to get the index of the first element, which is 0 while GetUpperBound(0) is used to get the index of last element. Hence, we can omit the error by using these two functions together.

Note The dimension for both GetLowerBound(int dimension) and GetUpperBound(int dimension) is determined by the array type, whether it is one-dimensional array or two-dimensional array as they have the different Rank. Make sure the dimension has the value of greater than 0 or Rank - 1.

The Conclusion #

In this study blog, we've explore what is Index was outside the bounds of the array in C#, why it happens and how to resolve it. You should always be aware with the indices of the array when you want to access its element. Make sure not to access index outside of its bound, which is the range [0 - N - 1], where N = length of the array. Thanks!

The Reference #

For further information, please visit:

IndexOutOfRangeException: https://learn.microsoft.com/en-us/dotnet/api/system.indexoutofrangeexception?view=net-7.0
GetLowerBound(Int32) in LINQ: https://learn.microsoft.com/en-us/dotnet/api/system.array.getlowerbound?view=net-7.0#system-array-getlowerbound(system-int32)
GetUpperBound(Int32): https://learn.microsoft.com/en-us/dotnet/api/system.array.getupperbound?view=net-7.0#system-array-getupperbound(system-int32)

py_cpp_pair

Tue, 12 May 2026 05:28:32 +0000

py_cpp_pair

Write C++ directly inside Python strings, auto-generate pybind11 bindings, compile on-demand, dynamically load the extension, and inject exported symbols into your Python globals.

Version: 1.0.0

Badges

PyPI: py_cpp_pair 1.0.0 (import name: py_cpp)
Python: 3.10–3.13
Platforms: Windows / Linux / macOS
CI: GitHub Actions

Install

pip install py-cpp-pair

Import name stays:

import py_cpp as pcp

Quickstart

import py_cpp as pcp

pcp.cpp("""
int add(int a, int b) {
    return a + b;
}
""")

print(add(5, 7))  # 12

Class support

import py_cpp as pcp

pcp.cpp(r"""
class Robot {
public:
    int power = 100;
    Robot() {}
    int attack() { return power * 2; }
};
""")

r = Robot()
print(r.attack())  # 200

Public API

Only these are intended as public:

pcp.cpp(code: str) -> module
pcp.install(package: str) -> bool
pcp.clear_cache() -> None
pcp.version() -> str

Cross-platform support

OS	Compiler used	Notes
Windows	MinGW-w64 `g++` (preferred)	Requires `g++` on `PATH`.
Linux	`g++`	Requires build tools installed.
macOS	`clang++`	Requires Xcode Command Line Tools.

Override the compiler via:

# Windows (PowerShell)
$env:PY_CPP_CXX = "g++"

# Windows (cmd.exe)
set PY_CPP_CXX=g++

# Linux/macOS (bash/zsh)
export PY_CPP_CXX=clang++

Optional best-effort auto-install (opt-in):

# Enable by setting an environment variable in your shell.
# The installer logic is OS-aware (Linux/macOS/Windows) and picks the best available path.

# Windows (PowerShell)
$env:PY_CPP_AUTO_INSTALL_COMPILER = "1"

# Windows (cmd.exe)
set PY_CPP_AUTO_INSTALL_COMPILER=1

# Linux/macOS (bash/zsh)
export PY_CPP_AUTO_INSTALL_COMPILER=1

One-shot (only for a single command):

# Windows (PowerShell)
$env:PY_CPP_AUTO_INSTALL_COMPILER="1"; python -c "import py_cpp.toolchain as t; t.ensure_compiler_available(); print('compiler ok')"

# Linux/macOS (bash/zsh)
PY_CPP_AUTO_INSTALL_COMPILER=1 python -c "import py_cpp.toolchain as t; t.ensure_compiler_available(); print('compiler ok')"

Note: after an installer runs, you may need to open a new terminal so PATH updates are visible.

vcpkg package management

Install a C++ library with:

import py_cpp as pcp
pcp.install("fmt")

If the port does not exist:

Sorry, library not found.

py_cpp_pair detects vcpkg via VCPKG_ROOT or PATH. If missing, it can auto-bootstrap by cloning vcpkg (requires Git).

Caching and build layout

py_cpp_pair caches builds by SHA256 hash of the C++ source. Reusing identical code reuses the compiled extension.

Per-user state is stored under PY_CPP_HOME if set, otherwise the OS-default data directory:

Windows: %LOCALAPPDATA%\\py_cpp
macOS: ~/Library/Application Support/py_cpp
Linux: $XDG_DATA_HOME/py_cpp or ~/.local/share/py_cpp

Subfolders:

builds/: compiled extensions per hash
cache/: toolchain artifacts (Windows Python import libs)
logs/: optional logs (enable with PY_CPP_LOG_FILE=1)

Troubleshooting

ImportError: DLL load failed (Windows): ensure MinGW runtime DLLs are visible. py_cpp_pair adds common DLL dirs automatically, but the compiler bin directory must be on PATH.
No compiler found: install g++/clang++ and ensure it is on PATH.
vcpkg bootstrap fails: install Git and retry, or set VCPKG_ROOT to an existing vcpkg checkout.

Performance notes

Compilation is cached by source hash; repeated calls are fast after the first build.
For larger projects, prefer fewer, bigger cpp() calls (each call creates a module).

Documentation

See docs/:

docs/installation.md
docs/architecture.md
docs/api.md
docs/package_manager.md
docs/troubleshooting.md
docs/examples.md

Roadmap

Better symbol detection (still regex-based by design)
Multiple translation units / headers
Better vcpkg library auto-linking
Optional clang-based parsing for richer bindings

Contributing

See CONTRIBUTING.md.

POSIX Shared Memory

Wed, 08 Apr 2026 12:50:12 +0000

POSIX shared memory allows to us to share a mapped region between unrelated processes without needing to create a corresponding file.

Linux uses a dedicated tmpfs file system mounted under the directory /dev/shm. This file system has kernel persistance - the shared memory objects that it contains will persists even if no process currently has them open, but they will be lost if the system is shut down.

To use a POSIX shared memory object, we perform two steps:

Use the shm_open() function to open an object with a specified name. The shm_open() function is analogous to the open() system call. It either creates a new shared memory object or opens an existing object. As its function result, shm_open() returns a file descriptor referring to the object.
Pass the file descriptor obtained in the previous step in a call to mmap() that specifies MAP_SHARED in the flags argument. This maps the shared memory object into the process's virtual address space.

 #include <sys/mman.h>
 #include <sys/stat.h>        /* For mode constants */
 #include <fcntl.h>           /* For O_* constants */

int shm_open(const char *name, int oflag, mode_t mode);
int shm_unlink(const char *name);

The name argument identifies the shared memory object to be created or opened. The oflags argument is a mask of bits of O_* as being in open() system call.

At any point, we can apply fstat() to the file descriptor returned by shm_open() in order to obtain a stat structure whose contain information about the shared memory object.

Example of creating a POSIX shared memory is here.

After created the memory object, we of course want to read and write the data into that. Data reading program is here and writing program is here.

SUSv3 requires that POSIX shared memory objects have at least kernel persistence; that is, they continue to exist until they are explicitly removed or the system is rebooted. When a shared memory object is no longer required, it should be removed using shm_unlink(). The example program of its usage is here.

In summary, a POSIX shared memory object is used to share a region of memory between unrelated processes without creating an underlying disk file. To do this, we replace the call to open() that normally precedes mmap() with a call to shm_open(). The shm_open() call creates a file in a memory-based file system, and we can employ traditional file descriptor system calls to perform various operations on this virtual file. In particular, ftruncate() must be used to set the size of the shared memory object, since initially it has a length of zero.

The Linux Programming Interface - Memory Mappings

Wed, 08 Apr 2026 11:50:41 +0000

Let's continue discussing the Linux programming with mmap() system call.

The mmap() system call creates a new memory mapping in the calling process's virtual address space. There are two types of mapping:

File mapping: A file mapping maps a region of a file directly into the calling process's virtual memory.
Anonymous mapping: An anonymous mapping doesn't have a corresponding file. Instead, the pages of the mapping are initialized to 0.

The memory in one process's mapping may be shared with mappings in other processes (MAP_SHARED). This can occur in two ways:

When two processes map the same region of a file, they share the same pages of physical memory.
A child process created by fork() inherits copies of its parent's mappings, and these mappings refer to the same pages of physical memory as the corresponding mappings in the parent.

We also set the memory mapping as private (MAP_PRIVATE) so that other processes cannot see the content of the memory mapping.

In total, we can use mmap() in four situations:

Private file mapping
Private anonymous mapping
Shared file mapping
Shared anonymous mapping

And don't forget exec() family erase and rebuild the process virtual memory so that memory mapping is lost.

If you type the man 2 mmap and see the its signatures:

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
int munmap(void *addr, size_t length);
int msync(void *addr, size_t length, int flags);
void *mremap(void *oldaddr, size_t oldsize, size_t newsize, int flags, ... /* void *newaddr */)

In here:

The addr argument indicates the virtual address at which the mapping is to be located. You should put the NULL so that kernel selects the proper address.
The length argument specifies the size of the mapping in bytes.
The prot argument is a bit mask specifying the protection to be placed on the mapping and can take PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC. For example, PROT_READ | PROT_WRITE means that mapping can be read and written but not executed.
The flags argument is a bit mask of options controlling various aspects and can be MAP_PRIVATE and MAP_SHARED.
The fd and offset arguments are just for file mapping. But, in case of anonymous mapping, it is good practice to set fd as -1.

Below is the simple anonymous file mapping program:

 #include "../linux.h"

void main(int argc, char *argv[])
{
   char *addr;
   int fd;
   struct stat sb;

   if (argc != 2 || strcmp(argv[1], "--help") == 0)
      usage_error("Wrong command-line usage");

   fd = open(argv[1], O_RDONLY);
   if (fd == -1)
      syscall_error();

   if (fstat(fd, &sb) == -1)
      syscall_error();

   addr = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   if (write(STDOUT_FILENO, addr, sb.st_size) == -1);
      syscall_error();

   exit(EXIT_SUCCESS);
}

As can be seen above, for file mapping (private or shared), the following steps are applied:

Obtain the file descriptor that is mapped, typically via a call to open().
Use stat() system call to get the file length in bytes.
Pass these variables to mmap() system call call with NULL as start address of mapping.

Below is the another example about shared file mapping:

 #include "../linux.h"

 #define MEM_SIZE 10

void main(int argc, char *argv[])
{
   char *addr;
   int fd;

   if (argc < 2 || strcmp(argv[1], "--help") == 0)
      usage_error("Wrong command-line usage");

   fd = open(argv[1], O_RDWR);
   if (fd == -1)
      syscall_error();

   addr = mmap(NULL, MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
   if (addr == MAP_FAILED)
      syscall_error();

   if (close(fd) == -1)       /* No longer need 'fd' */
      syscall_error();

   printf("Current string=%.*s\n", MEM_SIZE, addr);

   if (argc > 2) {            /* Update contents of region */
      if (strlen(argv[2]) >= MEM_SIZE)
         usage_error("String too long");
      
      memset(addr, 0, MEM_SIZE); /* Zero out region */
      strncpy(addr, argv[2], MEM_SIZE - 1);
      if (msync(addr, MEM_SIZE, MS_SYNC) == -1)
         syscall_error();

      printf("Copied \"%s\" to shared memory\n", argv[2]);
   }
   exit(EXIT_SUCCESS);
}

In this example, we see the writing 10 bytes to shared memory mapping after the zeroing a partition of file mapping. In addition, we see the msync() system call. It is actually optional but good practice when writing to disk. It ensures that the 10 bytes are written to disk.

In addition to MAP_PRIVATE and MAP_SHARED, Linux allows a number of other values to be included in the mmap() flags argument:

MAP_ANONYMOUS
MAP_FIXED
MAP_LOCKED
MAP_HUGETLB
MAP_NORESERVE
MAP_PRIVATE
MAP_POPULATE
MAP_SHARED
MAP_UNINITIALIZED

Please read the manual page (man 2 mmap) to learn these flags.

When talking about memory mapping and virtual memory layout, I wanna give you some virtual memory operations. There are four main system call:

The mprotect() system call changes the protection on a region of virtual memory.
The mlock() and mlockall() system calls lock a region of virtual memory into physical memory.
The mincore() system call allows a process to determine whether the pages in a region of virtual memory are resident in physical memory.
The madvise() system call allows a process to advise the kernel about its future patterns of usage of a virtual memory region.

Signatures of these system calls:

int mprotect(void *addr, size_t len, int prot);
int mlock(const void *addr, size_t len);
int mlockall(int flags);
int munlock(const void *addr, size_t len);
int munlockall(void);
int mincore(void *addr, size_t length, unsigned char *vec);
int madvise(void *addr, size_t length, int advice);

Below is the simple program about changing the memory protection mapped by mmap() system call.

 #include "../linux.h"

 #define LEN          (1024 * 1024)
 #define SHELL_FMT    "cat /proc/%ld/maps | grep zero"
 #define CMD_SIZE     (sizeof(SHELL_FMT) + 20)

void main(int argc, char *argv[])
{
   char cmd[CMD_SIZE];
   char *addr;
 
   addr = mmap(NULL, LEN, PROT_NONE, MAP_SHARED | 
               MAP_ANONYMOUS, -1, 0);
   if (addr == MAP_FAILED)
      syscall_error();
 
   /* Display line from /proc/self/maps corresponding to mapping */
 
   printf("Before mprotect()\n");
   snprintf(cmd, CMD_SIZE, SHELL_FMT, (long) getpid());
   system(cmd);
 
   /* Change protection on memory to allow read and write access */
 
   if (mprotect(addr, LEN, PROT_READ | PROT_WRITE) == -1)
      syscall_error();

   printf("After mprotect()\n");
   system(cmd);

   exit(EXIT_SUCCESS);
}

In here, firstly I've mapped a shared anonymous memory. mprotect() changes the memory mapping's from none to read and write protections. To see the this change, we can inspect the /proc/PID/maps file.

Until here, I gave you the overall memory mapping techniques. I'll explain the shared memory which is the most effective data transmission IPC mechanism of Linux in further article.

Resource:

Kerrisk M., The Linux Programming Interface, no starch press, 2010

Simple Code Injection into ELF Executable

Mon, 06 Apr 2026 20:12:17 +0000

In this tutorial, I will explain an code injection technique into ELF executable.

Firstly, you need to understand the ELF executable, its contents, sections, symbol table or so on. I've written a dedicated article previously. So if you don't have any information about ELF, please read it firstly and then come here again.

Let's say we have the following source file:

/**
  * Simple Code Injection
  */

 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>

int main(int argc, char *argv[])
{
int i, num;

        num = 10;

        for (i = 0; i < num; i++)
        {
              printf("#%d\n", i);
        }
        return EXIT_SUCCESS;
}

Compile this source file and then run it:

$ gcc main.c -o main ; ./main

After that, you will see:

 #0
 #1
 #2
 #3
 #4
 #5
 #6
 #7
 #8
 #9

In here, I will change the num = 10 to num = 5 so that the output will be #0 to #4.

To accomplish this, I need to find the corresponding machine instruction/s. According to your background, you need to know that num variable will be in the .text section of ELF executable. Because it is the local variable. To display the .text section of the program, objdump is the primarily tool:

$ objdump -j .text -d main

The output will be as following:

(...)

0000000000001149 <main>:
    1149:f3 0f 1e fa          endbr64
    114d:55                   push   %rbp
    114e:48 89 e5             mov    %rsp,%rbp
    1151:48 83 ec 20          sub    $0x20,%rsp
    1155:89 7d ec             mov    %edi,-0x14(%rbp)
    1158:48 89 75 e0          mov    %rsi,-0x20(%rbp)
    115c:c7 45 fc 0a 00 00 00 movl   $0xa,-0x4(%rbp)
    1163:c7 45 f8 00 00 00 00 movl   $0x0,-0x8(%rbp)
    116a:eb 1d                jmp    1189 <main+0x40>
    116c:8b 45 f8             mov    -0x8(%rbp),%eax
    116f:89 c6                mov    %eax,%esi
    1171:48 8d 05 8c 0e 00 00 lea    0xe8c(%rip),%rax        # 2004 <_IO_stdin_used+0x4>
    1178:48 89 c7             mov    %rax,%rdi
    117b:b8 00 00 00 00       mov    $0x0,%eax
    1180:e8 cb fe ff ff       call   1050 <printf@plt>
    1185:83 45 f8 01          addl   $0x1,-0x8(%rbp)
    1189:8b 45 f8             mov    -0x8(%rbp),%eax
    118c:3b 45 fc             cmp    -0x4(%rbp),%eax
    118f:7c db                jl     116c <main+0x23>
    1191:b8 00 00 00 00       mov    $0x0,%eax
    1196:c9                   leave
    1197:c3                   ret

Which machine instruction/s corresponds to num = 10? You need to know reading the assembly instructions in here. The answer is the movl $0xa,-0x4(%rbp) assembly instruction. Because the stack pointer of the program was enlarged by 4 bytes (int holds 4 bytes of memory) to lower address and put the immediate 0xA value. So that I need to change the 0xA value to 0x5.

After the found required assembly instruction, I need to determine the memory address of it. If you look at center column, the machine instruction is c7 45 fc 0a 00 00 00. In here:

c7: the opcode of movl register
45 fc: the displacement of -0x4(%rbp)
0a 00 00 00: the immediate value, 0xA (little-endian)

c7 byte resides at 0x115c address so that 0a byte at 0x115f.

To change that byte, I'm gonna use hexedit program:

$ hexedit ./main

You will see:

After that, you move to 0x115F address and change the 0x0A value to 0x05. Save the changes and then run the program again. You will see:

 #0
 #1
 #2
 #3
 #4

That's it. You injected the new code in the ELF executable .

This technique is simple and powerful. But there are some limitations. The most important one is that you should not shift the byte addresses, just replace it. If you wanna change the entire ELF executable addresses, you need the other techniques. That's the next article's topic.

Interrupt Management in ARM Cortex-M

Mon, 06 Apr 2026 15:15:30 +0000

Interrupts is the must-known concept in embedded programming. So I wanna explain the interrupt management in ARM Cortex-M in this tutorial.

ARM architecture distinguishes between the two types: interrupt and system exception. Interrupts are primarily sourced by external hardware like UART that warns about arrival of data. System exceptions are more software-related and caused by ARM Cortex internal.

Interrupts and system exceptions are exchangeably used. But even if both of these do same thing (especially in programming), the differences are important for us, engineers!

I'll use "interrupt" word for both terms further, if otherwise declared.

Before diving into interrupts, you need to understand the general execution workflow of ARM Cortex. There are two types of execution modes: thread and interrupt. After resetting the microcontroller, execution flow starts in thread mode so that if you want to use interrupts, you need to enter the interrupt mode. But how?

When you flash your firmware into microcontroller (base address of 0x08000000, in case), ARM Cortex starts to execute the firmware's machine instructions in thread mode. If you want to use any interrupt, you have to explicitly say it to ARM Cortex by using Interrupt Service Routines (ISRs). ISRs are actually standard C functions, but have the special signatures. I'm gonna explain it later.

The most important question about interrupts is that why do we need interrupts?

The answer: Interrupts are the source of multiprogramming!

Interrupts give us second execution flow besides the main flow (executed in thread mode by default). It also gives the context switch mechanism for RTOS. I will explain it lastly.

ARM Cortex has a special hardware called Nested Vectored Interrupt Controller (NVIC). It handles and manages the all interrupt usage. Below is the its simple schematic:

Another important dedicated hardware is the EXTI Controller. The peripheral interrupts in the microcontroller directly are connected to NVIC. But If you want to use interrupts over microcontroller pins (like detecting rising or falling edge of a button), you have to use EXTI lines. Microcontroller pins are grouped and tied to specific EXTI lines. Please look at the reference manual to find it.

We have many different types of interrupts. For now, let's look at these:

ARM Cortex has defined 15 fixed system exceptions (coming from internal of Cortex). But microcontroller vendors specify also variable-length interrupts (coming from external of Cortex). For example, STM32 series microcontrollers allow up to 256 interrupts.

But where are located these interrupts? The answer is the at vector table.

The vector table is an array of word data inside the system
memory, each representing the starting address of one exception type [1].

If you've flashed any firmware into microcontroller over OpenOCD + GDB, you've seen probably the this vector table. If you've not, let's see it exactly.

I have STM32F446RE microcontroller and ST-LINK connection. I've compiled a firmware (firmware.elf) to flash it. Open a terminal and type:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

And open the second terminal and type:

$ arm-none-eabi-gdb firmware.elf

Lastly, type these into GDB session:

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load

After flashed the firmware into microcontroller, you will see:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x1080 lma 0x80001d0
Loading section .rodata, size 0x10 lma 0x8001250
Loading section .init_array, size 0x4 lma 0x8001260
Loading section .fini_array, size 0x4 lma 0x8001264
Loading section .data, size 0x10 lma 0x8001268
Start address 0x80011d0, load size 4716
Transfer rate: 9 KB/sec, 786 bytes/write.

Yeah! You see the interrupt vector table (_.isr_vector_) section was flashed at the base address of flash memory and other sections after the vector table. If you use any type of interrupt, the ARM Cortex gets the corresponding ISR handler from there so that ARM Cortex exactly knows the ISR handler addresses. You just need to select the required ISR handler function!

As I said before, ISR handlers are special type of C functions. But why? Because the handlers have predefined function prototypes. You have to use these function prototypes. Otherwise, ARM Cortex cannot find it and treated as normal C functions, not the ISR handlers.

These predefined handler prototypes are stored in the startup code. For STM32F446RE, it is _startup_stm32f446xx.S_ file. Below is a part of this startup code:

(...)

  .word  Reset_Handler
  .word  NMI_Handler
  .word  HardFault_Handler
  .word  MemManage_Handler
  .word  BusFault_Handler

(...)

  .word     CAN1_TX_IRQHandler                /* CAN1 TX                      */                         
  .word     CAN1_RX0_IRQHandler               /* CAN1 RX0                     */                          
  .word     CAN1_RX1_IRQHandler               /* CAN1 RX1                     */                          
  .word     CAN1_SCE_IRQHandler               /* CAN1 SCE                     */                          
  .word     EXTI9_5_IRQHandler                /* External Line[9:5]s          */                          
  .word     TIM1_BRK_TIM9_IRQHandler          /* TIM1 Break and TIM9          */         
  .word     TIM1_UP_TIM10_IRQHandler          /* TIM1 Update and TIM10        */         
  .word     TIM1_TRG_COM_TIM11_IRQHandler     /* TIM1 Trigger and Commutation and TIM11 */
  .word     TIM1_CC_IRQHandler                /* TIM1 Capture Compare         */                          
  .word     TIM2_IRQHandler                   /* TIM2                         */                   
  .word     TIM3_IRQHandler                   /* TIM3                         */                   
  .word     TIM4_IRQHandler                   /* TIM4                         */                   
  .word     I2C1_EV_IRQHandler                /* I2C1 Event                   */                          
  .word     I2C1_ER_IRQHandler                /* I2C1 Error                   */                          
  .word     I2C2_EV_IRQHandler                /* I2C2 Event                   */                          
  .word     I2C2_ER_IRQHandler                /* I2C2 Error                   */          

(...)

At the beginning, I've stated that interrupts are the source of multiprogramming. This is core logic behind the RTOS!

RTOSes use the interrupts to create many tasks. In classic firmware written with RTOS, there are many tasks that the RTOS kernel have to handle and manage. You can think that task in the firmware corresponds to process in the computers.

The RTOS kernel needs to execute these tasks in order and with same time-slice so that the kernel cuts the one task execution and passes to the next task execution using context switches. This is done by using interrupts. For example, FreeRTOS kernel uses SVC and PendSV interrupts specificly to make the contex switch. Apart from that, the RTOS kernel uses also the SysTick interrupt to give the equal execution time to each task.

Got it. I've explain the interrupt management in ARM Cortex-M in general. I put the some references below. You can look at the interrupts and similar topics in there.

References:

[1]. Yiu J., The Definitive Guide to The ARM Cortex-M3, Second Edition, Newnes, page 36.
Noviello C., Mastering STM32, 0.26 Release, Leanpub

How to build a firmware using Makefile?

Mon, 06 Apr 2026 15:13:09 +0000

In embedded programming, we trust IDEs like STM32CubeIDE, Keil or so on. These IDEs give us just some buttons and UIs to build, flash, and debug the source code that we've written for a MCU. But, I think that every engineer that works on this field have to know that how these steps are made by hand.

In this tutorial, I will show building a firmware written for STM32F446RE MCU with just using a single Makefile.

Below is the project directory:

$ tree
.
├── bin/
├── drivers/
│   ├── CMSIS/
│   ├── STM32F446RETX_FLASH.ld
│   └── STM32F4xx_HAL_Driver/
├── lib/
├── Makefile
└── src/
    ├── it.c
    ├── main.c
    ├── main.h
    └── peripheral.c

Firstly, which libraries do we need to have?

HAL library
CMSIS library
Linker script
Startup/system code
arm-none-eabi-* tools

I've put the all required libraries/scripts into /drivers directory. Please download these using:

$ git clone --recurse-submodules https://github.com/STMicroelectronics/STM32CubeF4.git
$ sudo apt install gcc-arm-none-eabi

In here, HAL library is used to program the peripherals and CMSIS for ARM-Cortex itself. These are the most important libraries that we have to get.

Apart from that, we also need some special files. First is the linker script. It includes the memory layout of microcontroller. Sometimes, it comes from above command. But if you cannot find it there, please install it externally. Another file is the startup code. It's written in Assembly language. As its name suggests, it's the first code that runs in microcontroller. Basically, it includes the Reset_Handler and a branch that jumps into main() function in your source code. Also system code includes the some generic and general definitions.

After downloaded and explained the required ones, Let's write the Makefile step by step:

1. Toolchain definitions

CC        := arm-none-eabi-gcc
OBJCOPY:= arm-none-eabi-objcopy
SIZE:= arm-none-eabi-size
RM        := rm -f
FILE:= file

2. MCU-specific definitions

DEVICE_FAMILY     := STM32F4xx
DEVICE_MODEL     := STM32F446xx
DEVICE_VARIANT     := STM32F446RETx

3. Compiler and linker flags

CORTEX_FLAGS     := -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
COMMON_FLAGS     := -g3 -Os -ffunction-sections -fdata-sections -Wall
AS_FLAGS             := -x assembler-with-cpp

In here, we've defined some flags:

-mthumb means that the firmware uses thumb (16-bit) instruction set.
-mcpu=cortex-m4 means the ARM-Cortex series itself.
-mfpu=fpv4-sp-d16 and -mfloat-abi=hard means that floating-point operations can be done in the firmware.

4. Include paths

MAIN_INC:= ./src
CMSIS_INC:= ./drivers/CMSIS/Include
CMSIS_DEV_INC:= ./drivers/CMSIS/Device/ST/STM32F4xx/Include
HAL_INC:= ./drivers/STM32F4xx_HAL_Driver/Inc
CMSIS_DSP_INC:= ./drivers/CMSIS/DSP/Include

In here, we specified the header files that are used in the source code.

5. Source and special files

MAIN_SRC:= $(wildcard ./src/*.c)
HAL_SRC:= $(wildcard ./drivers/STM32F4xx_HAL_Driver/Src/*.c)
SYSTEM_SRC:= ./drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c
STARTUP_CODE:= ./drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/startup_stm32f446xx.S
LINKER_SCRIPT:= ./drivers/STM32F446RETX_FLASH.ld

6. Sorthands and build definitions

DEFINES:= -D$(DEVICE_FAMILY) -D$(DEVICE_MODEL) -D$(DEVICE_VARIANT) \
-DUSE_HAL_DRIVER

SOURCES:= $(MAIN_SRC) $(HAL_SRC) $(SYSTEM_SRC)
OBJECTS:= $(notdir $(patsubst %.c,%.o,$(SOURCES))) startup_stm32f446xx.o
INCLUDES:= -I$(MAIN_INC) -I$(CMSIS_DEV_INC) -I$(CMSIS_INC) -I$(HAL_INC) \
-I$(CMSIS_DSP_INC)

CFLAGS:= $(CORTEX_FLAGS) $(COMMON_FLAGS) $(DEFINES) $(INCLUDES)
AFLAGS:= $(CORTEX_FLAGS) $(AS_FLAGS) $(DEFINES) $(INCLUDES)
LDFLAGS:= $(CORTEX_FLAGS) -T $(LINKER_SCRIPT) \
-Wl,--gc-sections,--relax --specs=nano.specs --specs=nosys.specs \
   -Wl,--start-group -lc -lm -lnosys -Wl,--end-group

In here, I mostly did the string operations and manipulations. But some points are interesting and need some explanations:

Firstly, I've grouped the sources and libraries and converted the source file suffixes into object file formats.
Also, I've created three total flags that will be used for compiling, assembling, and linking phases.
In linker flags, I put the linker script. As you noticed, this step will be done after the compiling the source files. I also linked the some libraries. -lc is the standard C library. In firmware, we use often string manipulation functions (strlen(), strcat(), strcpy() or so on), snprint(), memset(), or similar ones. -lm is the math library as you know. -lnosys means that I'm just implementing the bare-metal firmware, there is no such as kernel or fully OS.

7. Output files

FIRMWARE_ELF:= firmware.elf
FIRMWARE_BIN:= firmware.bin

Generally, we use the ELF file when flashing and debugging. ELF executable includes the both machine code, metadata, debug information, symbol table or similar stuffs. In contrast, BIN executable just includes the machine code. If you look at the size of both, you will use the ELF executable is much bigger!

8. The recipe

.PHONY: all

all:
@echo "-------------------------------------"
@echo "----- Building the source files -----"
@echo "-------------------------------------"
@$(CC) $(AFLAGS) -c $(STARTUP_CODE)
@$(CC) $(CFLAGS) -c $(SOURCES)

@echo "\n------------------------------------"
@echo "----- Linking the object files -----"
@echo "------------------------------------"
@$(CC) $(LDFLAGS) $(OBJECTS) -o $(FIRMWARE_ELF)
@$(OBJCOPY) -O binary $(FIRMWARE_ELF) $(FIRMWARE_BIN)
@$(RM) $(OBJECTS)

@echo "\n-------------------------------------"
@echo "----- The firmware memory usage -----"
@echo "-------------------------------------"
@$(SIZE) $(FIRMWARE_ELF)

@echo "\n-------------------------------------"
@echo "----- The firmware binary format ----"
@echo "-------------------------------------"
@$(FILE) $(FIRMWARE_ELF)

Lastly, run the Makefile:

$ make

That's it . You've built the both firmware.elf and firmware.bin.

You are ready to flash the built firmware into microcontroller with this or similar command (over ST-Link connection):

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program firmware.elf verify reset exit"

I've also published a repository for that. You can look at it from here: https://github.com/CanGulmez/Embedded-Firmware-with-Makefile

Flashing and Debugging A Firmware in Detail

Mon, 06 Apr 2026 14:53:30 +0000

In this tutorial, I will inspect, flash and debug a firmware written for STM32F446RE microcontroller. To accomplish this, we need some dedicated tools:

openocd
arm-none-eabi-*
gdb-multiarch

openocd is the primarily tool that we have to get. It's used as bridge between your host machine and debugger hardware. (I'm using use ST-Link hardware in this time). I will use it to connect to the debugger hardware. arm-none-eabi-* tools are the ARM toolchain used in development of the firmware. gdb-multiarch is the debugger too.

You can get these tools:

$ sudo apt install openocd gcc-arm-none-eabi gdb-multiarch

Note: I'm on Ubuntu 24.04, gcc-arm-none-eabi tools don't include the gdb debugger like arm-none-eabi-gdb. So that gdb-multiarch is being installed externally. On some distribution, the gdb debugger comes with gcc-arm-none-eabi.

Suppose that I have a firmware called "firmware.elf" and wanna inspect it as first step.

The first thing that you should do probably is to determine the firmware itself:

$ file firmware.elf
firmware.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped

The file command simply outputs the firmware properties like the endiannes, architecture, or so on. You can see easily that this firmware was written for 32-bit ARM Cortex.

We can see also the section sizes (in bytes) of the firmware with arm-none-eabi-size command:

$ arm-none-eabi-size firmware.elf
   text   data    bss    dec    hexfilename
   5252     20   1732   7004   1b5cfirmware.elf

If you are not familiar with sections of the executables, I've wrote many tutorials that explains the ELF executable. You can look at there.

If you exactly wanna see the contents of the firmware, arm-none-eabi-objdump is the primarily tool for that:

$ arm-none-eabi-objdump -j .text -d firmware.elf

firmware.elf:     file format elf32-littlearm


Disassembly of section .text:

(...)

0800079c <main>:
 800079c:b500      push{lr}
 800079e:b091      subsp, #68@ 0x44
 80007a0:f000 f8ac bl80008fc <HAL_Init>
 80007a4:f000 f82c bl8000800 <configOscClk>
 80007a8:f000 f844 bl8000834 <configDebugPort>
 80007ac:4911      ldrr1, [pc, #68]@ (80007f4 <main+0x58>)
 80007ae:4d12      ldrr5, [pc, #72]@ (80007f8 <main+0x5c>)
 80007b0:4c12      ldrr4, [pc, #72]@ (80007fc <main+0x60>)
 80007b2:4668      movr0, sp
 80007b4:f7ff ff08 bl80005c8 <strcpy>
 80007b8:4668      movr0, sp
 80007ba:f7ff ff81 bl80006c0 <strlen>
 80007be:f04f 33ff mov.wr3, #4294967295@ 0xffffffff
 80007c2:b282      uxthr2, r0
 80007c4:4669      movr1, sp
 80007c6:480d      ldrr0, [pc, #52]@ (80007fc <main+0x60>)
 80007c8:f000 fdc2 bl8001350 <HAL_UART_Transmit>
 80007cc:4629      movr1, r5
 80007ce:4668      movr0, sp
 80007d0:f7ff fefa bl80005c8 <strcpy>
 80007d4:4668      movr0, sp
 80007d6:f7ff ff73 bl80006c0 <strlen>
 80007da:f04f 33ff mov.wr3, #4294967295@ 0xffffffff
 80007de:b282      uxthr2, r0
 80007e0:4669      movr1, sp
 80007e2:4620      movr0, r4
 80007e4:f000 fdb4 bl8001350 <HAL_UART_Transmit>
 80007e8:f44f 707a mov.wr0, #1000@ 0x3e8
 80007ec:f000 f8b2 bl8000954 <HAL_Delay>
 80007f0:e7ec      b.n80007cc <main+0x30>
 80007f2:bf00      nop
 80007f4:0800146c .word0x0800146c
 80007f8:08001489 .word0x08001489
 80007fc:20000084 .word0x20000084

(...)

For example, you see the main() function in .text section of the firmware. At left, the address of the machine code were being displayed. At center, you see the machine code corresponding to assembly instructions that is at right side.

Inspecting the contents of ELF executable is huge topic. It has many variants and view-of-points in there.

"Flashing" term means writing the dedicated sections of the firmware into the flash memory area of the microcontroller. It's done with many different ways. But I will show you openocd tool.

In here, I have to define that how exactly does openocd work. It actually creates a server into the host machine with given configuration files. After starting the server session, you need to connect to that server over telnet or gdb.

Let's do it. Firstly, connect the microcontroller to the host machine. Then open a terminal session and type this command:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg

In here, I gave the two configuration files. First is the interface. As I said, I use the ST-Link connection. Second is the target file. It defines the target architecture. The openocd comes a bunch of configuration files. So search it and find the appropriate configuration files.

You will see something like this:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J33M25 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.224656
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections

The openocd attached the 4444 port to telnet and 3333 port to gdb. So that I will bind the 3333 port in the gdb session.

Secondly, open the second terminal and type:

$ gdb-multiarch firmware.elf

At the moment, you are in the gdb session. In here, bind to the 3333 port:

(gdb) target remote localhost:3333

For now, you are in the control and responsible for the all flashing and debugging operations.

To flash the firmware, use these commands:

(gdb) monitor reset halt
(gdb) load
(gdb) monitor reset halt

There are tons of commands you can type in the gdb session. We can split these commands in two categories. monitor <command-name> commands directly are run by the openocd command. Other commands are run by the gdb itself.

load is the main command to flash the firmware. Before and after that command, resetting and halting the CPU execution is good practice. Output will be like:

Loading section .isr_vector, size 0x1c4 lma 0x8000000
Loading section .text, size 0x126c lma 0x8000200
Loading section .rodata, size 0x4c lma 0x800146c
Loading section .ARM, size 0x8 lma 0x80014b8
Loading section .init_array, size 0x4 lma 0x80014c0
Loading section .fini_array, size 0x4 lma 0x80014c4
Loading section .data, size 0xc lma 0x80014c8
Start address 0x08001400, load size 5272
Transfer rate: 9 KB/sec, 753 bytes/write.

That means that the firmware successfully was flashed .

If you just wanna flash the firmware and not debugging, this following command is enough:

$ openocd -f interface/stlink.cfg -f target/stm32f4x.cfg -c "program firmware.elf verify reset exit"

Instead of dealing with two terminal sessions, above command is just the one-step operation.

The main reason opening the second gdb session is to make the debugging. If you did the debugging previously, you will be familiar with these commands:

(gdb) break main
(gdb) continue
(gdb) next
(gdb) finish
(gdb) print var
(gdb) x/16wx *ptr
(gdb) set var
(gdb) list

The debugging operations are huge and will not fit into a single tutorial as you guest. So that I don't wanna dive into the these and other operations. But I wanna give you a good reference: The Art of Debugging with GDB, DDD, and Eclipse written by Norman Matloff and Peter Jay Salzman.

Until here, I gave a overall explanation the end-to-end pipeline. I'll explain the other stuffs in further.

ERROR (expected nested-name-specifier before ‘namespace’)-Fixed

Mon, 30 Mar 2026 03:20:18 +0000

The 'ERROR (expected nested-name-specifier before ‘namespace’)` error you may get while compiling your C++ code with a C++ compiler, this kind of issue might frustrate one, here we will discuss in the depth about the issue.

Photo by Rachel Vine

What is "ERROR (expected nested-name-specifier before ‘namespace’)"?
Why "ERROR (expected nested-name-specifier before ‘namespace’)" happens?
How to resolve "ERROR (expected nested-name-specifier before ‘namespace’)":
1. Solution:
Conclusion

What is “ERROR (expected nested-name-specifier before ‘namespace’)”?

Before discussing the error, we should know, what is a nested name specifier?

C++ nested name specifiers are the prefixes to qualified names. For example, “foo::” in “foo::x” is a nested name specifier. Nested name specifiers are made up of a sequence of specifiers, each of which can be namespace, type, identifier (for dependent names), decltype specifier, or the global specifier (‘::’). The last two specifiers can only appear at the start of a nested-namespace-specifier.

#include
#include

template
class ListPtr;

template
class ListPtrIterator {

public:
ListPtrIterator( ListPtr* _user ):
M_user( _user ),
M_cur( M_user->begin() ) {}

bool
cur( T*& );

bool
reset( void ) {
M_cur =M_user->begin();
return M_cur!=M_user->end();
}

private:
ListPtr* M_user;
typename list::iterator M_cur;
^^^^
ERROR: expected nested-name-specifier before 'list'
};

Output

new.cpp:28:46: warning: multi-character character constant [-Wmultichar]

 ERROR: expected nested-name-specifier before 'list'

Why does “ERROR (expected nested-name-specifier before ‘namespace’)“ happens?

As the compiler suggests that there is an with the list. Here the compiler does not accept the list as it is. Compiler accepts it as std::list.

As we know if we do not use the using namespace std in our program then we will face an error saying may be like that cout was not declared in this scope. But we know that in the past we did not need to define the using namespace std in the program. But now we have to use it or we have to use cout as std::cout.

In the program given above the cause is pretty similar to this reason.

Following is the error message you get:

` main.cpp online 2:7: error: expected nested-name-specifier before ‘namespace’ using namespace std; ^~~~~~~~~`

How to resolve “ERROR (expected nested-name-specifier before ‘namespace’)”?

Solution :

As I mentioned earlier, in the program given above the cause is pretty similar to this reason. So we have to use std::list to resolve the error since compilers do not accept containers without nested-name-specifier.

⚠️ Remember to use C++11 (otherwise you'll receive an error saying that extended initializer lists are only available with -std=c++11 or -std=gnu++11)..

ℹ Ensure that the relevant header files are included.

Conclusion:

We discussed in this article about ERROR (expected nested-name-specifier before ‘namespace’) discussed and a number of solutions to get around it, one final way out may be be to upgrade to a more recent compiler version

Error does not name a type C++

Mon, 23 Mar 2026 09:40:17 +0000

Error does not name a type in C++

The "error does not name a type" in C/C++ is defined as the when user declares outside of the function or does not include it properly in the main file this error will through.

Why this error occurs?
How to resolve:
Conclusion

Why this error occurs?

File: sample.h  
 #ifndef SAMPLE_H__<br />#define SAMPLE_H__
   namespace Sampletest {
    class CP_M_ReferenceCounted<br />{<br />};
    }
    #endif
    <br />File : test.cpp
#include "sample.h"
    typedef CP_M_ReferenceCounted FxRC;
   <br />int main(int argc, char **argv)<br />{
    <p>return 0;<br />}

If you run the above code you will get the error "...error: CP_M_ReferenceCounted does not name a type"

How to resolve :

To overcome this error follow this two methods of solutions

Solution 1:

To avoid this error, we have to add the "using namespace Sampletest" at the start of the program in C++.

<p>File : test.cpp</p>
<p><code>#include "sample.h"</p>
<p>//Add the following to your code</p>
<p>using namespace Sampletest</p>
<p>typedef CP_M_ReferenceCounted FxRC;</p>
<p><br />int main(int argc, char **argv)<br />{</p>
<p>return 0;<br />}</code></p>

Solution 2:

To avoid this kind of error we need to add the header "#include sample.h" at the starting of the program in C++.

Same Problem while declaring outside of the function

These kinds of errors are also acquired while printing outside of any function.
A statement which isn't declaration in C++ need to be printed inside of the function

File test.cpp

<p>#include <iostream><br />#include <cstring><br />using namespace std;</p>
<p>struct Node{<br />char *name;<br />int age;<br />Node(char *nc = "", int ax = 0){<br />name = new char[strlen(nc) + 1];<br />strcpy(name, n);<br />age = ax;<br />}<br />};</p>
<p>Node node1("Roger", 20), node2(node1);<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;<br />strcpy(node2.name, "Wendy");<br />node2.name = 30;<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;</p>
<p> </p>
<p><b>Output :</b></p>
<p>error: ‘node2’ does not name a type</p>
<br/>

Solution 3:

To avoid these types of errors you need to add everything inside the function,
because a statement that isn't a declaration in C++ needs to be inside the function

<p><code>int main() {<br />Node node1("Roger", 20), node2(node1);<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;<br />strcpy(node2.name, "Wendy");<br />node2.name = 30;<br />cout << node1.name << ' ' << node1.age << ' ' << node2.name << ' ' << node2.age;<br />}</code></p>

Conclusion:

In this article, we have seen why the undefined error occurs in C/C++ and discussed how to resolve these errors in various methods.

Porting Test Drive II from SNES to PC, Part 5: Making scanline validation repo-owned

Sat, 21 Mar 2026 13:48:21 +0000

Porting Test Drive II from SNES to PC, Part 5: Making scanline validation repo-owned

The cleanup thread in this repo is still product work.

That point is easy to miss when a change is small. The commit I closed today, 224057d on 2026-03-19, does not add a new renderer, a new extractor, or a new visible gameplay result. What it does is remove another place where the archaeology loop could silently lean on mutable shared emulator output.

That matters more than it sounds.

The last cleanup checkpoint was only half the job

The previous cleanup commit, d06ac64, moved the boot-probe path onto repo-owned outputs by default.

That was a good checkpoint, but it did not close the whole class of problem.

There was still a committed scanline-validation path that defaulted to Mesen's shared LuaScriptData area:

validation/mesen_scanline_step_test.lua
tools/capture_visible_mode7_range.py

That meant a helper could still read from a mutable emulator-owned location unless the caller was careful.

In a repo like this, that is a real risk:

the same script can be run many times across different frame windows
multiple archaeology lanes can be active in parallel
old probe JSON can look plausible enough to reuse by mistake
automation becomes harder to reason about when "latest file wins"

The whole point of the cleanup track is to make that kind of accidental ambiguity harder.

What changed in this checkpoint

This iteration was intentionally narrow.

The generic Mesen launcher, validation/run_mesen_capture.sh, now prepares the parent directory for TD2_SCANLINE_TEST_OUTPUT_PREFIX before launching the emulator.

That means the scanline probe can be given a repo-owned destination without relying on the caller to pre-create the directory tree.

Then the committed visible-range helper, tools/capture_visible_mode7_range.py, was updated so that it no longer defaults to shared LuaScriptData.

Instead, when you run something like:

python3 tools/capture_visible_mode7_range.py \
  1094 1101 \
  --output tools/out/visible_mode7_1094_1101.json

the helper now derives a repo-owned raw probe prefix beside the aggregate output:

tools/out/visible_mode7_1094_1101_scanline_probe/td2_scanline_step_test.json

It also records that raw probe path in the aggregate JSON payload, so the run is easier to trace later.

That is the important pattern:

one command
one explicit aggregate output
one repo-owned raw probe surface attached to that run

No silent dependence on whatever happened to be left in .mesen-config/Mesen2/LuaScriptData.

Why this matters for archaeology

This project is already juggling several different kinds of evidence:

emulator captures
bridge extracts
direct ROM-derived builders
runtime manifests
scanline probes
contract checks

That is healthy, but only if the repo keeps a strong boundary between:

authoritative artifacts
scratch intermediates
stale leftovers from old experiments

Shared emulator output blurs that boundary.

Repo-owned per-run output sharpens it again.

That pays off immediately in a few ways:

validation commands become easier to rerun without cleanup guesswork
aggregate JSON can point back to the exact raw probe surface it used
it becomes clearer which artifacts belong to the repo's evidence chain
future automation can assume less hidden global state

None of that is glamorous, but it is exactly the kind of work that keeps a reverse-engineering-heavy port from becoming fragile.

What this checkpoint does not solve

It is important not to oversell this.

This commit does not finish the validation-output cleanup track.

In particular, it does not yet absorb the newer gameplay-oriented scanline wrapper that is currently sitting in the dirty worktree. That helper is part of active lane work and should be closed as its own checkpoint instead of being folded into a cleanup commit by accident.

So the state after 224057d is:

boot-probe output defaults are repo-owned
the committed visible-range scanline helper now follows the same policy
the broader scanline/gameplay cleanup surface is still open

That is the right level of scope for one iteration.

Where the project stands now

The repo's overall posture is still the same:

Lane 1 bank30 unresolved queue closure remains the official top gate
Lane 2 tilemap provenance has solid contiguous coverage through 1086..1117
Lane 3 gameplay archaeology is active and currently lives deep in visible-phase scanline work
the cleanup/refocus track is still running in parallel so those archaeology lanes stay trustworthy

This checkpoint belongs to that last category.

It is small, but it makes the validation surface more deterministic, and that gives the later archaeology results a better floor to stand on.

Next step

The next cleanup-side step is straightforward:

push the same repo-owned/per-run policy through the remaining scanline and gameplay wrappers
keep trimming lingering doc examples that still assume shared emulator output

After that, the project can keep pressing the more interesting blockers:

the 958..977 bootstrap gap
the 986+ final-screen composition gap
the callback-family replacement work beyond the current intro coverage

That is the shape of progress here.

Not every useful checkpoint produces a new frame.

Some of them make sure the next frame result is actually believable.

Porting Test Drive II from SNES to PC, Part 3: Provenance instead of screenshots

Sat, 21 Mar 2026 13:29:08 +0000

Porting Test Drive II from SNES to PC, Part 3: Provenance instead of screenshots

Once the SDL runtime could play a real intro path, the next bottleneck was not rendering. It was evidence.

If a frame looked close, that was no longer enough. The project needed to answer harder questions:

Which ROM chunk produced the visible tilemap?
Which callback path was active when that chunk was used?
Is this frame a stable source window, or just a screenshot that happens to match today?

That is the phase that starts on March 5 and dominates the repo through March 17.

The repo grew a dedicated archaeology workspace

Commit 6a12991 on 2026-03-05 added the rom_analysis/ workspace and a lot of the tooling that now defines the back half of the project:

build_bank30_chunk_registry.py
build_mesen_design_pack.py
build_mesen_design_pack_range.py
extract_compression_header_manifest.py
validate_td2_chunks.py
summarize_l001210_trace.py
new roadmap and checkpoint docs under rom_analysis/docs/

This was a useful structural move for two reasons.

First, it separated "runtime code that has to ship frames" from "analysis code that has to explain frames." Those concerns overlap, but they are not the same job.

Second, it made the archaeology lane explicit. The repo stopped treating bank 10, bank 11, and bank 30 as vague future work. It started giving them artifacts, checkpoints, and pass or fail surfaces.

`L001210` became the main provenance hook

The core trace target in this phase is L001210, the dispatcher at 00:9210 that is tied to chunk usage. The project added probe-side tracing and summary tooling so it could move from static bank scanning to runtime-backed provenance.

That flow looks like this:

make -C tools l001210-probe L001210_PROBE_TOTAL_FRAMES=3600 MESEN_TIMEOUT_SECONDS=90
make -C tools l001210-trace-summary
make -C tools bank30-registry

By itself, a bank scan tells you where candidate compressed blocks exist. It does not tell you which ones matter in a live frame window. The L001210 trace changed that.

The bank-30 registry could now classify candidates by both decode status and runtime visibility. As of the current snapshot, the unresolved queue is still concrete:

1E:E91F
1E:EE7F
1E:DA96
1E:9681

That is better than a hand-wavy "some bank 30 work remains." It is a small list of named unresolved producers with evidence attached.

Design packs made the frame data usable outside the emulator

The project also stopped treating raw Mesen dumps as the final output format.

mesen_ppu_extract and the design-pack builders turned frame windows into bundles that can be inspected like assets instead of debugger state:

per-layer visible renders
decoded tilemaps
tile sheets
sprite analysis
raw VRAM/CGRAM/OAM
stable manifests for a frame or a frame range

That gave the repo a middle layer between emulator internals and runtime playback. The port could still consume raw scene files, but the engineer could now inspect the same frame as:

raw SNES memory
decoded tilemap entries
sprite metadata
a runtime sequence window

That is why later provenance work stays readable. The project has actual frame packages, not just screenshots and prose.

Provenance windows got promoted one range at a time

The best example is the tilemap-to-ROM provenance chain around the late attract path.

Commit bd239a0 on 2026-03-13 promoted provenance windows through 1101. The next commit, 7614c8f, pushed that contiguous reading through 1117. Those windows are not just captured frames. They carry a source argument.

The current reading in the roadmap is very specific:

bg1 is the visible main-screen layer across the promoted window
chrBaseWords = 0x2000
runtime provenance steps through three chunk anchors:
- 1094..1095 -> 0D:C4DC
- 1096..1100 -> 07:BF49
- 1101..1117 -> 07:C112

That is the kind of statement that changes implementation strategy. Once a port effort knows which visible block comes from which chunk family, asset conversion and runtime replacement can be targeted. Without that, every new frame range looks like a one-off.

The repo is careful here in a way I like: it does not overclaim continuity. It explicitly treats 1117 as the current confidence edge and avoids pretending that later frames are solved by carry-over alone.

The same tooling started reaching gameplay

This archaeology phase is not limited to front-end cleanup.

Commit 36767ce captured the first deterministic track-1 seed window for frames 86..93. Commit 207d8f6 followed with a bounded sweep. The current roadmap now says:

.mesen-config/Mesen2/SaveStates/game_11.mss is a usable deterministic seed
b_hold is the first nontrivial dynamic lane
the queue cursor equalization path is directly observed through frames 90..92

That is exactly the right style of progress for gameplay-era reverse engineering. It is not "bank 10 is understood." It is "this input schedule on this savestate produces this specific observable state transition window."

The later timed-input extraction work in 802f804 extends the same method to a different provenance problem. The repo recovered a later direct-hit cluster around:

7051 -> 0D:C4DC
7059 -> 07:BF49
7064 -> 07:C112

Again, the useful part is not just that those frames were found. It is that they were found under a deterministic scripted-input lane and packaged with provenance outputs.

What changed in practice

Before this phase, the repo could say:

this frame range matches the emulator closely
this runtime path seems to work

After this phase, the repo could say:

this frame range belongs to callback family 01:9FE5
this visible tile block maps to specific chunk producers
this gameplay seed window is reproducible from a known savestate and input schedule
these bank-30 candidates remain unresolved even after matrix sweeps

That is a different level of engineering maturity.

It also changes what "port progress" means. A project like this does not move linearly from renderer to gameplay. It moves by reducing uncertainty in the places where rendering, content, and control flow meet.

By mid-March, asmdump had become good at that:

deterministic capture
design-ready frame bundles
trace-backed chunk provenance
promoted source windows with explicit confidence edges

That set up the next phase cleanly. Once the repo could explain its frame windows, the next pressure point was obvious: the validation surface had to become stricter, and the repo itself had to get cleaner so generated output did not drown the actual evidence.

Porting Test Drive II from SNES to PC, Part 2: The first native intro slice

Sat, 21 Mar 2026 13:28:35 +0000

Porting Test Drive II from SNES to PC, Part 2: The first native intro slice

The first two days in asmdump were about measurability. The next phase, from February 28 through March 2, was about replacing a narrow front-end slice with native code.

That is the point where the project stopped proving that it could extract data and started proving that it could replay behavior.

The runtime target was small on purpose

The port/ runtime was never meant to be a full game engine in week one. It was a controlled execution environment for known assets and known frame windows.

By this stage, port/README.md already described a focused runtime:

SDL2 window and renderer
fixed 60 Hz loop
256x224 framebuffer
direct SNES BG rendering from extracted VRAM + CGRAM + PPU state
optional OBJ composition from extracted OAM
sequence playback for extracted scene windows
indexed palette-animation playback for compact native clips

That last distinction mattered immediately. Some intro segments are better represented as sampled frame sequences. Others are better represented as a native state machine driven by extracted data.

The project did not try to answer that in the abstract. It answered it on one scene.

Why the Ballistic splash was the right first target

The Ballistic intro window is anchored cleanly at frame 654. It is also a good engineering target:

it is deterministic under no input
it is presentation-heavy but structurally simple
it is mostly a palette-driven BG scene, not a sprite-heavy gameplay state

The repo ended up carrying three versions of the same clip:

a measured reference clip from deterministic screenshots
a ROM-derived clip generated from helper-scene CGRAM plus the A39C palette ramp
a compact callback asset for direct runtime playback via ballistic_a39c

That progression matters. The measured clip proves what the frame window should look like. The ROM-derived clip proves that the asset path can reconstruct it from source data. The callback asset proves that the runtime can execute a compact native representation instead of replaying a bag of screenshots.

By the time commit aa67d27 landed on 2026-02-28, the repo had already marked the milestone directly: "reproduce intro animation natively."

Hybrid playback was a feature, not a compromise

One of the best early decisions in this project was to allow hybrid manifests instead of forcing every frame range into the same representation.

That produced several useful runtime artifacts:

tools/out/ballistic_native_sequence.txt
tools/out/ballistic_rom_sequence.txt
tools/out/ballistic_callback_sequence.txt
tools/out/intro_loop_hybrid_sequence.txt
tools/out/intro_loop_hybrid_bridge_visible_sequence.txt

The project used those manifests to keep progress moving while specific windows remained unresolved.

The no-input intro loop is the clearest example:

direct runtime ballistic_a39c playback covers the Ballistic segment
sampled bootstrap playback bridges the unstable 958..977 window
queue-driven snes_bg replacements cover frames 978 and 982
later attract states can be swapped between sampled and native bridge-visible windows as coverage improves

This is a better engineering shape than an all-or-nothing rewrite. Every new native window can replace a sampled window when it is good enough, without destabilizing the rest of the loop.

The bootstrap and bridge work forced more precise tooling

The easy story would have been "render the Ballistic clip and move on." The real story is that getting beyond it forced the repo to model the transition frames precisely.

The project added:

repeatable L00A00C scene building
decoded WRAM queue summaries for the bootstrap window
queue-driven scene builders for post-Ballistic frames
OAM-aware snes_bg playback
bridge-visible Mode 7 scene models for the late attract path

That is how the repo got to statements that are actually useful:

frame 978 and frame 982 can be reconstructed from the queued VRAM/OAM path
frame 986 is close on the BG side but still wrong in OBJ composition
late bridge-visible frames through 1093 can run natively in the SDL runtime, even when screenshot parity is still open for some of them

The runtime command surface reflects that evolution:

make -C port

./port/build/td2_port --sequence ./tools/out/ballistic_callback_sequence.txt
./port/build/td2_port --sequence ./tools/out/intro_loop_hybrid_sequence.txt
./port/build/td2_port --sequence ./tools/out/intro_loop_hybrid_bridge_visible_sequence.txt
./port/build/td2_port --headless --sequence ./tools/out/intro_loop_hybrid_bridge_visible_sequence.txt --sequence-no-loop --frames 1418 --dump-prefix ./port/build/intro_loop_hybrid_bridge_visible

At this point the port is no longer just "an SDL viewer for extracted images." It is executing multiple representations of front-end state:

pure extracted scene windows
compact callback assets
palette-driven indexed animations
queue-derived bridge scenes

That is the real milestone.

The code had to be reorganized early

Commit 8858823 on 2026-03-01 is one of the most practical commits in the whole history. It split a 3083-line main.c into:

td2_types.h
td2_io.c/.h
td2_ppu.c/.h
a much smaller main.c

That same commit also added:

docs/bootstrap_9D69_analysis.md
docs/bank10_11_30_notes.md
port/test_regression.sh

This is not incidental cleanup. It is the point where the runtime stopped being a prototype and started becoming an environment that other port work could live inside.

There are two reasons that matters:

The PPU and scene-loading path were already complicated enough to deserve their own modules.
The reverse-engineering notes and the runtime code had started to depend on each other in both directions.

Once the project reached hybrid intro playback, runtime work and archaeology work were no longer separate lanes. The runtime needed more exact hardware facts. The archaeology needed a runtime that could replay extracted states and make errors visible.

First native launch means more than "the window opened"

Commit 87a3f67 on 2026-03-02 is named "first native launch running intro anim." The important part of that message is not "launch." It is "running intro anim."

At that point, the project had already moved from:

raw ROM and disassembly
to deterministic captures and extraction
to a PC runtime capable of replaying a real front-end path with native logic in the loop

That is the point where the questions get more expensive and more interesting.

You are no longer asking:

Can I decode this chunk?
Can I render this tilemap?

You are asking:

Which frames still need sampled playback?
Which callbacks can be promoted to native code?
Where does the remaining mismatch come from: BG state, OAM state, queue timing, Mode 7 math, or presentation order?

That is why the next phase in the repo turns hard toward provenance, callback tracing, and window-by-window archaeology. Once the renderer can play the intro, the bottleneck is no longer drawing. The bottleneck is explaining exactly where each visible window comes from.

Porting Test Drive II from SNES to PC, Part 1: Day 0 to a measurable ROM

Sat, 21 Mar 2026 13:28:13 +0000

Porting Test Drive II from SNES to PC, Part 1: Day 0 to a measurable ROM

Between February 26 and March 19, 2026, the asmdump repo moved through 45 commits. It started as a raw reverse-engineering dump and ended this stretch with a C/SDL runtime, deterministic emulator probes, tilemap provenance tooling, and regression gates.

This first part covers the first two days: what was in the repo on day 0, why the project did not start with gameplay code, and how the initial extraction and validation toolchain changed the shape of the problem.

Day 0: the repo was a reverse-engineering base

Commit a683c61 on 2026-02-26 is the real starting point. It imported:

bank0.asm through bank31.asm
game.smc and game.sym
ROM build files like Makefile, linkfile, main.s, snes.asm, and spc700.asm

That is enough to rebuild and inspect the ROM. It is not enough to port it.

There was no extraction pipeline. There was no deterministic capture harness. There was no stable asset format that a PC runtime could load. The repo knew a lot about addresses, but very little about contracts.

The absence of a direct decompilation path matters here. bank0.asm already exposed recognizable reset, NMI, IRQ, and callback scheduling logic, but the gameplay-facing banks were not in a state where a straight assembly-to-C pass would be a good use of time:

bank10.asm and bank11.asm still mixed code and data heavily
bank30.asm looked more like structured tables and dispatcher data than a clean list of callable functions
game.sym exposed labels and coverage, not behavior

So the early plan was not "translate bank 0, then bank 1, then bank 10". The early plan was:

Make the original ROM measurable.
Extract typed data from it.
Rebuild systems on the PC side against those measured outputs.

That decision is still the right one. A reliable port needs a reference harness before it needs more C files.

The first burst of tooling

February 27 has nine commits. That entire day is the actual day-1 port effort.

The important commits are:

c867efd - SNES asset extraction toolchain scaffolding
fcc30b5 - scene, sprite, and road visualization tooling
f8785b9 - fully integrated Qt asset viewer UI
2bc9dc2 - initial scripts, sprite translation, capture data, and the first runtime skeleton

The repo stopped treating the ROM as a monolith and started turning it into inspectable outputs:

palette dumps as JSON
VRAM reconstruction and boot-screen manifests
decompressed chunk outputs
tile sheets rendered to neutral image formats
Mesen-based screenshot and state capture
scene visualizers that could be driven outside the emulator

Representative commands from that stage still describe the approach well:

./validation/run_mesen_capture.sh

python3 tools/extract_bank3_palettes.py game.smc tools/out/bank3_palettes.json
python3 tools/extract_boot_screen_manifest.py game.smc tools/out/bank1_boot_screen.json
python3 tools/build_boot_vram.py game.smc tools/out/bank1_boot_screen.json tools/out/bank1_boot_vram_variant0.bin --json-out tools/out/bank1_boot_vram_variant0.json
python3 tools/decompress_td2_chunk.py game.smc tools/out/bank7_42fb_8000.bin --bank 7 --addr 0x8000 --json-out tools/out/bank7_42fb_8000.json

None of that is glamorous. All of it is necessary.

The early validation/ scripts mattered because they made the emulator part of the build surface instead of a manual debugging tool. mesen_capture.lua gave the project deterministic frame dumps and input logs. mesen_probe_boot.lua started recording boot and title-state selectors frame by frame. Once those existed, "what does the ROM do here?" stopped being a memory question and became a file question.

Typed outputs changed the project

The most important change in those first two days was not the number of tools. It was the move toward typed outputs.

There is a real difference between:

"I have a PNG of the title screen"
and "I have VRAM, CGRAM, OAM, PPU state, decompressed source chunks, and the command sequence that built this screen"

The first is useful for discussion. The second is useful for engineering.

By the end of the initial toolchain burst, the repo already had examples of that second category:

tools/out/bank3_palettes.json
tools/out/bank1_boot_screen.json
tools/out/bank1_boot_vram_variant0.json
tools/out/bank7_42fb_8000.json
deterministic Mesen capture logs under .mesen-config/Mesen2/LuaScriptData/

That gave the project a clean boundary between "ROM-side fact" and "PC-side implementation". It also made later runtime work much less fragile. The SDL renderer could target stable files instead of scraping live emulator output or hard-coding one-off frame knowledge.

Why the visualizers mattered

fcc30b5 and f8785b9 are easy to dismiss as UI work, but they are part of the core engineering story.

The early scene, sprite, road, and Qt viewer tools turned opaque ROM state into something an engineer could inspect without rebuilding the entire mental model every session. That is not polish. That is throughput.

On a project like this, the fast path is rarely "write more code". The fast path is usually:

expose the data
make it inspectable
reduce the number of manual emulator steps between a hypothesis and a rendered result

That principle shows up all over the repo after day 1. The later design packs, provenance windows, regression gates, and scanline samplers are all extensions of the same idea.

What the repo looked like after the first real day

By the end of 2bc9dc2, the repo had crossed a line:

it still was not a gameplay port
it still was not a decompilation
but it was no longer just a disassembly dump

It had become a measurable workbench:

deterministic captures
extraction scripts
decompression tooling
typed manifests
visual inspection tools
the first C/SDL runtime skeleton under port/

That last item is where the next part starts. Once the reference side was strong enough, the obvious next step was not more extraction. It was to take one narrow front-end slice and get it running natively.

That slice ended up being the Ballistic intro path, and it forced the project to answer a harder question than "can I decode this asset?":

"Which parts of the intro are best represented as raw extracted state, and which parts need a native callback-driven implementation?"

Enhanced TENEX C shell

Sun, 08 Feb 2026 04:27:16 +0000

etcsh is an enhanced version of the original tcsh, which is a version of the original Berkeley C shell implementing file name completion and command line editing.

etcsh features the following enhancements and fixes over the original tcsh.

• Function declarations;

• read to variables from pipes and redirections;

• comments on interactive sessions;

• tell whether stdin is empty or not;

• variable expansion on expressions corrected;

• piped built-ins are forked;

• missing test built-in implemented;

• read-write variable flag;

• exit shall cancel lists.

More is to come. Feedbacks and contributions are much appreciated.

Integrating TON blockchain into Trust Wallet: a case study

Mon, 19 Jan 2026 03:18:04 +0000

I had TON cryptocurrency. I had Trust Wallet. But I couldn't use them together — TON simply wasn't supported.

I could have waited. Instead, I decided to build it myself.

A month later, TON was live in a wallet with 130 million users.

The Grant That Almost Fell Through

I noticed that TON Foundation was offering development grants. I applied. Almost immediately, they reached out — we hopped on a call and talked it through.

At the same time, I messaged a friend who worked at Trust Wallet. Together, we set up a group chat: Wallet Core developers, the TON team, my engineer friend, and me.

Then things got complicated.

Trust Wallet has two parts. Wallet Core is open-source and handles transaction signing. After discussing it in our chat, I realized we could contribute there. But there's a second part — app interaction (fetching balances, broadcasting transactions). That's closed-source. Only Trust Wallet's internal team can build it.

And that means: management approval, allocated engineering time, accountability. Trust Wallet can't just say "sure, we'll ship it next month."

TON Foundation had doubts:

What if Trust Wallet never adds it to the app? Why fund the grant?

Eventually, both teams met in the middle. TON approved the grant; Trust Wallet committed to prioritizing the integration. Win-win: a new blockchain and users for Trust Wallet, a new wallet and users for TON.

We started coding. My friend did most of the development — I reviewed and refined. We merged the PR in about a month.

How Trust Wallet Works Under the Hood

Trust Wallet runs on three platforms: Android, iOS, and a browser extension.

At its core is Wallet Core — an open-source library supporting over 130 blockchains. Written in C++ and Rust. It's not just used by Trust Wallet; other major wallets like Crypto.com rely on it too. The library handles:

Private key generation
Address creation and validation
Transaction signing
Smart contract interactions

This is where we added TON.

An Unexpected Bonus: Code from Everscale

Few people know the full story.

Originally, Durov launched TON, with TON Labs handling part of the development. After US sanctions, Durov stepped away — but TON Labs didn't. They continued building a fork called Free TON, which later became Everscale.

Then a new TON Foundation emerged, endorsed by Durov. It's now integrated into Telegram and has taken off, becoming a leading TON blockchain.

Here's the thing: TON Labs did a lot of impressive technical work. Everscale was already in Wallet Core. We extracted the shared code into a module called CommonTON.

That code now powers both Everscale and TON.

What Makes TON Unique

Your Wallet Is a Smart Contract

In TON, a wallet isn't just an address — it's a full-fledged smart contract. Everscale uses the older V3 wallet; for TON, we implemented V4R2.

Transaction Structure

In order to create a transaction from wallet, you have to send a message to the wallet smart contract:

External Message (from user to their contract)
├── header: sender's contract address
├── stateInit: code and data (first transaction only)
└── body:
    ├── signature: Ed25519 signature
    └── signing_message:
        ├── wallet_id, expire_at, seqno
        └── Internal Message (to recipient)
            ├── header: "send Y nanotons to address Z"
            └── body: transfer comment

I won't go too deep here. You can read more about the V4 wallet in the docs — including the source code.

Cells and BOC — A Unique Data Model

All data in TON is represented as a tree of cells (Bag of Cells). Each cell holds up to 1023 bits of data and up to 4 references to other cells.

Here's how we create a cell with V4R2 wallet data:

Cell::Ref WalletV4R2::createDataCell() const {
    CellBuilder builder;

    builder.appendU32(0);                       // sequence_number
    builder.appendU32(walletId);                // wallet_id
    builder.appendRaw(publicKey.bytes, 256);   // public key
    builder.appendBitZero();                   // "no plugins" flag

    return builder.intoCell();  // Total: 321 bits
}

To build a transaction, you assemble these cells correctly: recipient address, amount, comment — all packed into a BOC. Luckily, the BOC serializer was already implemented.

Address Formats

Everscale only has raw addresses:

0:4f6bbb5de550f01a5b73792ceca77d8c933ab396a1e300eb0ab5a5f49a430986

TON also supports a user-friendly format:

EQBPa7td5VDwGltzeSzsp32MkzqzlqHjAOsKtaX0mkMJhq_B

This is a base64 string that includes address type information and a checksum. The checksum helps catch typos in seed phrases.

Why Tonkeeper and Trust Wallet Are Incompatible

The Mnemonic Problem

Standards rule the blockchain world. Much of what originated in Bitcoin is still used today. BIP39 (Bitcoin Improvement Proposal) describes how to derive a private key from a seed phrase. The formula: seed = hash(mnemonic + salt).

By standard, salt = "mnemonic" + password.

In TON, salt = "TON default seed".

The result: the same seed phrase produces different keys in Tonkeeper vs. Trust Wallet. You cannot transfer a wallet between them.

This isn't unique to TON — the same issue exists with Waves, Qtum, and Polkadot (sr25519).

Checksum Validation

TON addresses include a checksum. If a user mistypes a word in their seed phrase and the checksum doesn't match, the wallet warns them immediately. This is another reason Tonkeeper and Trust Wallet wallets aren't interchangeable.

Beyond Wallet Core

In addition to the Wallet Core implementation, I provided Trust Wallet's team with code examples: how to fetch transaction data, query wallet state, and more. I also consulted on app integration questions related to TON. Also added blockchain info and the logo to the assets repository.

The Result

I connected with the TON and Trust Wallet teams. My friend and I built the integration. The code now runs in Trust Wallet across all platforms.

January 2023 — the PR was merged into Wallet Core.

Numbers:

130 million Trust Wallet users gained access to TON
Grant for blockchain integration: $4,250
Grant for adding Jettons: $4,000

Code:

TON in Wallet Core — main integration
Jettons (TON tokens) — added later

A few months later, I added Jettons, then moved on to other projects for TON and NEAR. But that's a story for another time.

Occasionally I share notes on development and more on Twitter

I would also like to say thank you to:
Tao Xu, Sztergbaum Roman, optout, Sergei, Viacheslav from Trust Wallet team - for organisation and code review

Kirill from TON Foundation - for helping me manage all of that, Narek - for tech support from TON, Steve Yun - for grant and support

Viacheslav - for implementing the main integration

Vladimir from Trust Wallet - for making it possible and for code review

And to everyone, who contributed to this project

How to round off double value to 2 decimal places in C++

Wed, 14 Jan 2026 13:24:47 +0000

Preciseness is crucial in programming, particularly when working with numerical quantities. It's common to need to round a double to a certain number of decimal places in a variety of fields, from scientific calculation to banking. We will look into C++ and examine several techniques to round a double to two decimal places in this article. Whether you're an experienced programmer or a novice to the field, knowing this basic function is essential to producing precise and well-rounded programs. Come along as we explore different approaches and practices to help you understand details of C++ rounding.

Rounding a Double Value to 2 Decimal Places in C++

1. Using round()

Programming frequently involves rounding a double to two decimal places, particularly in mathematical or financial applications. We'll look at a simple C++ technique to do this.

STEP 1: Create a double variable that holds the value you want to round.
STEP 2: Multiply the double by 100 to shift the decimal two places to the right.
STEP 3: Round the result using the 'round()' function from the'' library.

#include 

#include 

int main() {

    // Example value to be rounded

    double value = 12.345;

    // Step 1: Multiply by 100

    double multipliedValue = value * 100;

    // Step 2: Round the result

    double roundedValue = round(multipliedValue);

    // Step 3: Divide by 100 to get the final rounded value

    roundedValue /= 100;

    // Display the result

    std::cout << "Original Value: " << value << std::endl;<br>
    std::cout << "Rounded Value: " << roundedValue << std::endl;<br>
    return 0;

}

The original number is first multiplied by 100 to shift the decimal two places to the right.
After that, the result is rounded to the nearest integer using the 'round()' method.
In order to return the decimal to its initial location and essentially round to two decimal places, we divide the result by 100.

Output:

2. Using 'std::setprecision'

Another way to round a double to two decimal places is to use the '' library's 'std::setprecision'function.

STEP 1: Include the necessary header files.
STEP 2: Use 'std::setprecision' to set the precision to two decimal places.
STEP 3: Use 'std::fixed' to ensure that the precision is applied to the decimal part.

#include 

#include 

int main() {

    // Example value to be rounded

    double value = 12.345;

    std::cout << "Original Value: " << value << std::endl;<br>
    // Step 1: Set precision to two decimal places

    std::cout << std::fixed << std::setprecision(2);<br>
    // Step 2: Display the rounded value

    std::cout << "Rounded Value: " << value << std::endl;<br>
    return 0;

}

By using 'std::setprecision(2)', we specify that we want two digits after the decimal point.
Even in cases where trailing zeros are present, 'std::fixed' makes sure that the accuracy is applied to the decimal portion.

Output:

FAQ Q:How do these methods handle edge cases, such as extremely large or small double values?
A: The methods provided are generally robust for a wide range of double values. However, extreme values may lead to precision issues. It's advisable to test and adapt the methods based on your specific application's requirement.

Some Alternative Approches

Some alternative method used to round off the decimal values as followed:

1. Using printf()

An alternate method is to round to two decimal places by using the 'printf' function and the format specifier "%.2f".

STEP 1: Include the necessary header file.
STEP 2: Use printf with the "%.2f" format specifier
STEP 3: Pass the double value as an argument to printf.

#include 

int main() {

    // Example value to be rounded

    double value = 12.345;

    // Step 1: Display the rounded value using printf

    printf("Original Value: %.3f\n", value);

    printf("Rounded Value: %.2f\n", value);

    return 0;

}

The "%.2f" format specifier in 'printf' indicates that we want two digits after the decimal point.

Output:

FAQ Q: Can I round to a different number of decimal places?
A: Yes, you can. Adjust the multiplier or precision value accordingly.

2. Using floor and ceil

This method utilizes the floor and ceil functions from '' to round the double to two decimal places.

STEP 1: Include the necessary header files.
STEP 2: Use 'floor' to round down and 'ceil' to round up.
STEP 3: Choose the rounded value based on proximity to the original.

#include 

#include 

int main() {

    // Example value to be rounded

    double value = 12.345;

    // Step 1: Round down and round up

    double roundedDown = floor(value * 100) / 100;

    double roundedUp = ceil(value * 100) / 100;

    // Step 2: Choose the rounded value based on proximity

    double roundedValue = (value - roundedDown < roundedUp - value) ? roundedDown : roundedUp;

    // Step 3: Display the result

    std::cout << "Original Value: " << value << std::endl;<br>
    std::cout << "Rounded Value: " << roundedValue << std::endl;<br>
    return 0;

}

'floor' and 'ceil' are used to round down and round up, respectively.The choice between the rounded down and rounded up values is made based on proximity to the original value.

Output:

3. Using Boost Library

For C++ programming, Boost offers a versatile collection of libraries. The 'numeric_cast' function from the Boost Numeric Conversion library will be used in this example to round a double to two decimal places.

STEP 1: Include the necessary header file.
STEP 2: Use boost::numeric_cast to round the double.

#include  

#include 

int main() {

    // Example value to be rounded

    double value = 12.345;

    // Step 1: Round the double using boost::numeric_cast

    try {

        double roundedValue = boost::numeric_cast(static_cast(value * 100 + 0.5)) / 100.0;

        // Step 2: Display the result

        std::cout << "Original Value: " << value << std::endl;<br>
        std::cout << "Rounded Value: " << roundedValue << std::endl;<br>
    } catch (const boost::numeric::bad_numeric_cast& e) {

        std::cerr << "Error: " << e.what() << std::endl;<br>
    }

    return 0;

}

'boost::numeric_cast' is used to perform the casting with rounding.
The try-catch block is used to catch any exceptions that may occur during the rounding process.
The formula static_cast(value * 100 + 0.5) / 100.0 effectively rounds the double to two decimal places using the numeric_cast mechanism.

Make sure you have Boost installed properly and that your compiler can find the Boost headers. If you still encounter issues, consider checking your Boost installation or consult the Boost documentation for the correct header and library settings.

FAQ Q: In Practical, why we are rounding a number to 2 decimal places? Where it is applied?
A: Numerous real-world applications frequently need rounding values to two decimal places, especially in areas where accuracy and clarity are critical. In the context of financial computations, consider the following real-world example:

Rounding to two decimal places provides a clear and standardized way to represent currency values. It aligns with common currency formatting conventions and makes it easier for users to understand.
Floating-point arithmetic can sometimes introduce small precision errors. Rounding to two decimal places helps mitigate these issues, especially in scenarios where exact precision is not critical.

References

Here are some reference links that can help you with rounding off double values:

C++ Reference (cppreference.com)
cppreference.com
C++ Standard - ISO/IEC 14882:
ISO/IEC 14882:2020 - International Standard for C++

[SOLVED] A project with an output type of class library cannot be started directly

Wed, 14 Jan 2026 12:11:33 +0000

Errors are frequently encountered in software development, and recognizing them is essential for debugging and developing one's coding abilities. Especially in Visual Studio or other comparable IDEs, one such problem that developers frequently run across is the error message "A project with an output type of class library cannot be started directly." This error occurs due to different reasons likewise, using incorrect project configuration or if we misunderstand the class functionality. You can resolve this error using correct project configuraing and understand class functionality before coding.

In this article, we'll look into the error message "A project with an output type of class library cannot be started directly", why it occurs, provide examples, and explain how to resolve it like you need to change the initial project to a web application or console application with an executable output type. As an alternative, you can create a new project (like a console programme) and include a reference to the class library project in it to test the functionality of the library. The error message is as shown:

What is the error?

This error message indicates that an attempt was made to run a project that was set up as a class library directly, but it was missing the necessary executable code to run on its own as an application. Class libraries are collections of reusable code that are meant to be used by different projects in the same software solution. Class libraries, in contrast to independently apps, without a central point of execution and so cannot be launched directly. Because there are no executable instructions in a class library project, trying to run the project will result in this error.

Why does this error occur?

1. Incorrect Project Configuration

The incorrect configuration of the project causes this problem; usually, the output type is set to "Class Library" rather than an executable output type like "Console Application" or "Windows Application." This error occurs when you try to run class libraries directly since they are not designed to be run that way. The code is as followed:

// MyClassLibrary.cs

using System;

namespace MyClassLibrary

{

    public class MyClass

    {

        public void MyMethod()

        {

            Console.WriteLine("Hello from MyClass!");

        }

    }

}

The error message is as followed:

Tip: Double-check the start-up project settings in your solution to avoid running non-executable projects directly.

2. Misunderstanding of Class Library Functionality

Class libraries are collections of reusable code components meant to be used by other projects, not executed directly. This error occurs when attempting to run a class library project that lacks a main entry point for execution, such as a main() function in C++ or a 'Main()' method in C#. The error code is as followed:

// MyClassLibrary.h

#pragma once

#include 

class MyClass {

public:

    void MyMethod() {

        std::cout << "Hello from MyClass!" << std::endl;<br>
    }

};

The error message is as followed:

How can you solve the error?

You can follow the following methods to resolve your error:

1. Correct Output Type Configuration

Steps for correcting output type configuration in Visual Studio

Open Project Properties
- In Visual Studio, right-click on the project in Solution Explorer.
- Select "Properties" from the context menu.
Navigate to Application Settings
- Go to the "Application" tab in the project properties window.
Change your Output Type
- Under "Output Type", ensure that it is set to an appropriate executable type such as "Console Application" or "Windows Application".
Apply Changes
- Click "OK" after "Applying" required modifications.

2. Create Separate Executable Project

Steps for creating separate executable project.

Step 1: Create MyClassLibrary (Class Library) Project

Open Visual Studio.
Click on "File" at the top left corner.
Choose "New" and then "Project".
Select the option "Class Library (.NET Core)".
Give your project a name like "MyClassLibrary" and click "Create".
Now, you can write your reusable code in this project.

Step 2: Create MyConsoleApp (Console Application) Project

Again, click on "File" at the top left corner.
Choose "New" and then "Project".
But this time, select "Console App (.NET Core)".
Name your project, maybe "MyConsoleApp", and click "Create".
Now, let's connect it to the class library.
Right-click on "Dependencies" in the Solution Explorer (on the right).
Select "Add Reference".
In the window that pops up, go to the "Projects" tab and check "MyClassLibrary".
Click "OK" to connect the projects.

Step 3: Use MyClassLibrary in MyConsoleApp

Open the file named "Program.cs" in the MyConsoleApp project.
At the top of the file, add a line like "using MyClassLibrary;" (for C#) or #include "MyClassLibrary.h" (for C++).
Now, you can use the classes and methods from your class library in your console application! Just write the code to call those methods inside the Main function.

Step 4: Set MyConsoleApp as the Starting Point

In the Solution Explorer, find your MyConsoleApp project.
Select "Set as Start-up Project" with a right-click on it.
This tells Visual Studio to start running your console application when you press the "play" button.

Step 5: Run Your Console Application

Press the "debug" button (or press F5) to run your console application.

In MyClassLibrary (Class Library) Project

// MyClass.cs

using System;

namespace MyClassLibrary

{

    public class MyClass

    {

        public void MyMethod()

        {

            Console.WriteLine("Hello from MyClass!");

        }

    }

}

In MyConsoleApp (Console Application) Project

using MyClassLibrary;

using System;

namespace MyConsoleApp

{

    class Program

    {

        static void Main(string[] args)

        {

            MyClass myClass = new MyClass();

            myClass.MyMethod();

        }

    }

}

The output is as shown

Best Methods to Avoid Mistakes in the Future

You can follow the following preventive measures to avoid error in the future:

To identify configuration mistakes early on, implement automated build and test procedures.
Identify the different project types and their objectives to ensure their proper use.
Regularly review and verify project properties, including output type and target framework.

FAQ Q: What is the main cause of the error "A project with an output type of class library cannot be started directly"?
A: The main cause is misconfiguring a project as a class library instead of an executable application.

Q: Can automated processes help prevent this error?
A: Yes, implementing automated build and test processes can catch configuration errors early in the development cycle.

Wrapping Up

In conclusion, misconfigurations or errors during development are frequently the cause of the problem "A project with an output type of class library cannot be started directly". It happens when you try to run a class library project that doesn't have an execution entry point. Developers should be aware of project kinds, choose the right starter project, and routinely check properties in order to avoid making mistakes like this one. Code reviews and automated procedures can help reduce the danger even more. By following best practices, one may able to reduce mistakes and keep a productive growth process. Continued productivity and efficiency are ensured by quick resolutions achieved through configuration verification.

References

Here are some reference links related to above error:

Microsoft Visual Studio Documentation
Visual Studio .NET Documentation

How to Generate Random Numbers from 1 to 6 in C++

Mon, 24 Nov 2025 00:21:36 +0000

To "generate random numbers from 1 to 6 in C++":

Use the C++ built-in library stdlib.h in the header.
Use the rand() function to generate random numbers.
Use the srand() function to generate a different number at each execution.
Use the time.h library in the header with the srand() function to get different values at each execution, as the value will change relative to the time, which is a better option compared to just using srand().
Use For-loop to check that numbers are generated randomly from 1 to 6 at each iteration.
Check if random numbers are generated upon each execution from 1 to 6.

Code to Generate Random Number

Step 1: Code Editor: Open Your Code Editor

To get started with code writing, you need to open your favorite code editor. I prefer to use the OnlineGDB compiler.

Step 2: Write Code: Start Writing Code in C++

Let's code in the code editor step by step.

Write Necessary Headers

#include <iostream> //this library is used to handle input and output
#include <stdlib.h> //library for random number generator a mandatory library
#include <time.h> //used for generating random value relative to time 
using namespace std;

Begin with defining all the libraries that are required throughout the function implementation. I used the stdlib.h library to generate the random numbers. time.h is used for all the time-related functions, and it is required to state the current time so that randomness is ensured. You also have to define other basic libraries including iostream and std to deal with all the input-output related operations in C++.

Tip: You can also use cstdlib and ctime library instead of stdlib.h time.h, as it is more specific to C++.

Create diceRoll() Function

int diceRoll()
{
    srand(time(0)); //this built-in function ensures that upon each execution a random number is generated
    cout<<"Roll a Dice"<<endl;
    //loop for generation number from 1 to 6
    for(int i=0; i<6; i++)
    {
    int numbers = (rand() % 6) + 1; // this function ensures that the reminder should be displayed and will be from within the range
    cout<<" ";
    cout << numbers;
    }
    cout<<endl;
    return 0;
}

Now, moving towards the creation of the diceRoll() function, here, I have defined the function return type int to pass the random values to the main function. The first thing is to initialize the srand() function that ensures that on each execution different values are generated, but for the surety, the better approach is to use the time(0) function from time.h library that saves the current time relative to starting value i.e. seeding value and passes it as an argument to the srand(time(0)) function. It will surely give a sequence of random values upon each execution.
Then, I create a for-loop to iterate the dice faces within the range of 1 to 6. In each iteration, whenever a random number is generated, the number will take modules with 6 to not exceed the range and should start with the number 1 and then store the values in the numbers variable. These sequences of numbers will be returned to the Main function.

Note: Make sure to use modules (%) as it will help to generate the number within your defined range.

Create the Main Function

int main(){
    cout <<"The Random numbers Generated from 1 to 6"<<endl;
    cout<<diceRoll(); // call the diceroll function
    return 0;
}

In the end, the Main function is defined to print the sequence of random numbers by calling the diceRoll() function.

Step 3: Code Compilation: Compile the code of Step 2

After writing the code, you must compile the code so that the results will display. If you are with me, just click the run button in the OnlineGDB compiler to start the compilation.

Step 4: Random Number Generated: Output

Congratulations! You have created a simple diceroll game by using the built-in function. Is not this easy? Yes, that is why the use of built-in libraries makes the problem easy for developers.

Alternative Approach: Using Random Library

Curious, is there any other method to generate random numbers in C++? Yes, In C++ 11, there is one more library introduced that is also used to generate random numbers. As rand() library is the default choice of many developers who have been using C++ for decades, but there are some limitations, as it is bound to some specific range using rand_max. Therefore, the random library overcomes this limitation by providing a vast range of distribution with better quality of randomness.

To "generate random numbers from 1 to 6 using Random library in C++":

Use the C++ built-in library random in the header.
Use the random_device defined in the library to get the start number i.e. seed value for generating a random number.
Use the mt19937 engine to generate a random number using a uniform distribution.
Use the uniform_int_distribution to generate numbers uniformly and define the range from 1 to 6.
Return the generated values to the Main function to display the Random number.

Code Demonstration using Random Library

#include <iostream> //this library is used to handle input and output
#include <random> //library is needed to generate a random number
using namespace std;
//the function in which a random number is generated for a simple dice roll game
int dicerolled()
{
   random_device rd; //this random_device is used to obtain the seed random system
   mt19937 gen(rd()); //this is the distribution which is used for generating number
   uniform_int_distribution<int> dist(1,6); //this piece of code defines the distribution range from 1 to 6 using a uniform distribution
   return dist(gen); 
} 
int main(){
    cout <<"The Random numbers Generated from 1 to 6"<<endl;
    cout<<"This is the results after using Random Library "<<endl;
    cout<<dicerolled();
    return 0;
}

In the above code of the diceRoll() function, I first create the random_device with the name "rd" that is used to obtain the starting seed to initialize the random system. After that I used the mt19937 algorithm to generate the number by using uniform_int_distribution range from 1 to 6 this will generate the random number and return it to the main function.

Note: random_device is the standard generator defined by the library

Note: There are many other algorithms instead of mt19937 if you want to use other engines for number generator you can go through the reference at the end of the page.

Output: Using Random Library

FAQs Q: What is the difference between rand() and srand() function?
A: The rand() stands for a random number whereas the srand() stands for a seeding random number both are the function of the same library that is used to generate random values but the srand() is used for stating the initial value for the sequence and to make sure that different value is generated when the program runs. Q: Can I use the same library in C language instead of C++?
A: Yes, there is not much difference in both the language only the slight syntax difference otherwise you can use the library in the C program as well. Q: Can I find the maximum and minimum range of random numbers using the rand() library?
A: Yes, you can find the maximum range by using the function RAND_MAX which provides the maximum value range that is exactly the range for int datatype but for minimum, the range always starts from 0.0.

Wrapping Up

In the end, you got to know how easily you can generate random numbers, whether to use the rand() function or an updated library i.e. random. However, there are some reasons for using each library. The rand() function can used if you are making a small-scale application because of its range limitation but, if you are making a large-scale application where the quality cannot neglect, then random is the best option because the random library provides a robust and flexible way to generate the number. C++ developer needs to understand the use case of each library to create a more robust simulation application. Thanks for reading the guide. Happy Coding!

Reference

How to solve "Undefined reference to 'sqrt' Error

Mon, 24 Nov 2025 00:11:55 +0000

Introduction :

If you are a newbie to C or C++ and are working with a math library, then you might get this error Undefined reference to `sqrt' . This error indicates that the compiler or linker couldn't find the definition for the sqrt function, which is used to calculate the square root of a number. To resolve this, you need to link your program with the math library. In your terminal, if you're using the GCC compiler for example, you can do this by adding -lm at the end of your command line. This ensures that the math library is correctly linked and the sqrt function is recognized. In this blog post, I will guide you in detail on how can you resolve this error.

Tip: Always ensure that you link your program to the math library by adding -lm at the end of your command line when you compile your program. E.g. when you compile your C program run a command like this in the terminal. here Main.c is the program that you want to compile and main is the program that you will get after compilation. gcc -o main Main.c -lm

Why did this error happen?

This error generally occurs when the math library, which contains the definition of the sqrt function, is not correctly linked to your program. (This error message indicates that when compiling or linking your code, the system couldn't find the necessary instructions for the sqrt function, which is commonly used for calculating square roots. This usually happens when the program is unable to locate the library or source code where sqrt is defined.) Without this link, your program doesn't know how to execute the sqrt function, hence the "undefined reference" error.

Here is a code block that might produce this error:

#include <stdio.h>

int main() {
   double num = 9.0;
   double root = sqrt(num);
   printf("square root of %.2f is %.2f", num, root);
   return 0;
}

Error by Compiler:

Causes for the "Undefined reference to `sqrt'" Error

1. Lack of Proper Linkage to the Math Library

The math library houses the 'sqrt' function definition. If your program is not properly linked to this library, it will not know how to execute the 'sqrt' function, hence the "undefined reference" error. For example, the following code snippet will produce an error because it does not link to the math library:

    #include<math.h>
    #include<stdio.h>
    
    int main() {
       double num = 9.0;
       double root = sqrt(num);
       printf("square root of %.2f is %.2f", num, root);
       return 0;
    }

To fix this, add -lm at the end of your command line when you compile your program. This ensures that your program is linked to the math library.

2. Syntax Error or Incorrect Usage of the 'sqrt' Function

Even if your program is properly linked to the math library, it can still produce an "undefined reference" error if there's a syntax error or incorrect usage of the 'sqrt' function. For example, forgetting to include the math library before using the 'sqrt' function will produce an error:

Error code:

#include <stdio.h>

int main() {
   double num = 9.0;
   double root = sqrt(num);
   printf("square root of %.2f is %.2f", num, root);
   return 0;
}

Caution: Don't miss to add " math library " at the header.

To fix this, ensure that you include the math library at the start of your program by adding #include <math.h>

Corrected code:

#include <stdio.h>
#include <math.h>

int main() {
   double num = 9.0;
   double root = sqrt(num);
   printf("square root of %.2f is %.2f", num, root);
   return 0;
}

3. Using an Outdated or Incompatible Compiler

Using an outdated or incompatible compiler might trigger this error. Different compilers might have different methods for linking libraries or different requirements for syntax. Make sure you're using a compiler that's compatible with your code and with the libraries you're using.

Solution for "Undefined reference to `sqrt'" Error

1. Properly Link Your Program to the Math Library

The most common cause of this error is not linking the math library correctly. You need to link your program to the math library in your code. This can be done by adding -lm at the end of your command when compiling your program. Here is how you can do it:

gcc -o program program.c -lm

In this command, program.c is the file you want to compile, and program is the name of the output file. The -lm flag ensures that the math library is linked properly.

2. Check Your Syntax and Usage of 'sqrt' Function

The 'sqrt' function is defined in the math library, so you need to ensure that you're including this library in your program. If you forget to do so, you'll get an "undefined reference" error. Here's how you can include the math library:

#include <math.h>

Here's an example of a program that correctly includes the math library and uses the 'sqrt' function:

#include <stdio.h>
#include <math.h>

int main() {
   double num = 16.0;
   double root = sqrt(num);
   printf("square root of %.2f is %.2f", num, root);
   return 0;
}

3. Use a Compatible Compiler

Different compilers might have different ways of linking libraries and different requirements for syntax. If you're still encountering the "undefined reference" error, you might want to try using a different compiler. For example, if you're currently using gcc, you might want to try using clang instead. Here's how you can do that:

clang -o program program.c -lm

In this command, **program.c** is the file you want to compile, and **program** is the name of the output file. The -lm flag ensures that the math library is linked properly.

Remember, the key is to ensure that your program is correctly linked to the math library, and to check your usage of the 'sqrt' function. If you keep these points in mind, you should be able to avoid the "undefined reference to `sqrt'" error.

Frequently Asked Questions

1. What does the "Undefined reference to `sqrt'" error mean? Ans. This error means that the compiler or linker couldn't find the definition for the sqrt function, which is used to calculate the square root of a number.

2. Why does the "Undefined reference to `sqrt'" error occur? Ans. This error generally occurs when the math library, which contains the definition of the sqrt function, is not correctly linked to your program. Without this link, your program doesn't know how to execute the sqrt function, hence the "undefined reference" error.

3. How do I fix the "Undefined reference to `sqrt'" error? Ans. You just need to link your program to the math library in your code. You can do this by adding lm at the end of your command line when you compile your program.

4. Why do I still get the "Undefined reference to `sqrt'" error even after linking to the math library? Ans. Even if your program is properly linked to the math library, it can still produce an "undefined reference" error if there's a syntax error or incorrect usage of the 'sqrt' function. Make sure to include the math library at the start of your program and check your usage of the 'sqrt' function.

5. Can using an outdated or incompatible compiler cause the "Undefined reference to `sqrt'" error? Ans. Yes, using an outdated or incompatible compiler might trigger this error. Different compilers might have different methods for linking libraries or different requirements for syntax. Make sure you're using a compiler that's compatible with your code and with the libraries you're using

Conclusion :

In conclusion, the "Undefined reference to 'sqrt'" error is a common issue faced by beginners in C or C++ programming. Understanding the causes and knowing how to resolve this error is crucial. Properly linking your program to the math library, checking your syntax and usage of the 'sqrt' function, and using a compatible compiler are the key steps to solving this error. Always remember to include the math library at the start of your program and check your usage of the 'sqrt' function. By following these steps, you should be able to compile and run your programs successfully without encountering this error. Happy coding!

How to Write a program to find the sum of the following series 1^1+2^2+3^3... in Python,Java and C

Mon, 24 Nov 2025 00:05:13 +0000

Introduction :

In this tutorial, we will learn how to write a program to calculate the sum of the series 1^1+2^2+3^3... in three popular programming languages: Python, Java, and C. This series is a mathematical sequence where each term is the number raised to the power of itself. The intriguing pattern of numbers is not only fascinating but also presents a good programming challenge. The quick solution to this problem involves writing a loop that iterates over a specified range of terms, raising each term to its own power, and then adding the result to a running total.

Tip: As we dive into the specifics of each language, remember that the logic remains consistent across languages. However, the syntax and specific functions used may differ.

The significance of series 1^1+2^2+3^3...?

The series 1^1+2^2+3^3... is significant in various mathematical and computational contexts. It is an example of a power series, where each term is a number raised to the power of itself. This kind of series has unique properties and patterns that make it an interesting subject for mathematical analysis. It can be seen in different mathematical conundrums and has relevance in the fields of number theory and calculus, among others.

From a computational perspective, implementing a program to calculate the sum of this series is a useful exercise in programming and algorithm design. Not only does it provide a practical application for loops and conditional statements, but it also allows for an exploration of efficiency and optimization. As the series grows, the computation can become quite complex, and writing a program to handle this efficiently is a valuable skill for any programmer.

Approach to Solving the Series

To find the sum of this series, we will follow a specific approach using loops and exponents.

Basic Logic:

Initialize a variable to keep track of the sum.
Create a loop that will iterate over the range of terms we want to calculate. This range should start from 1 because the first term of our series is 1^1.
For each iteration, calculate the current term by raising the current number to its own power. In Python, this can be done using the operator; in Java, we use Math.pow(), and in C, we can use the pow() function from the math.h library**.
Add the calculated term to our sum.
Repeat steps 3 and 4 for each term in the series.
After the loop ends, the variable will hold the sum of the series.

Example:

Let's say we want to calculate the sum of the first three terms of the series.

Initialize the sum to 0.
The loop will iterate over the range 1 to 3.
For the first iteration, we calculate 1^1 (which equals 1) and add it to our sum. The sum is now 1.
For the second iteration, we calculate 2^2 (which equals 4) and add it to our sum. The sum is now 5.
For the third iteration, we calculate 3^3 (which equals 27) and add it to our sum. The sum is now 32.
The loop ends, and our sum (32) is the sum of the first three terms of the series.

Caution: Make sure you correctly implement the logic for raising each term to its own power. This is a crucial step, and mistakes here could lead to incorrect results.

Program in the Python language :

Here is a Python code snippet that calculates the sum of the series 1^1+2^2+3^3... up to n terms:

def sum_of_series(n):
    sum = 0
    for i in range(1, n+1):
        sum += i**i
    return sum

print(sum_of_series(5))  # Output: 3413

Output :

In this code, we first define a function called sum_of_series which will do the job of adding up the numbers in our series. The n in the brackets is a placeholder for the number of terms we want to add up in the series.

Inside the function, we create a variable sum and set its initial value to 0. This variable will hold the running total of the sum as we add each term of the series.

We then start a loop with for i in range(1, n+1):. This loop will repeat a set of actions for each number in the series, starting from 1 and going up to n.

In the loop, we have sum += i**i. This line takes each number i in our series, raises i to the power of i (which is what i**i means), and adds the result to our running total sum.

After the loop has added up all the terms in the series, return sum gives us back the final total sum.

Finally, print(sum_of_series(5)) uses our sum_of_series function to calculate the sum of the first 5 terms of the series. The result, which is 3413, is then printed out.

Tip: Remember that the sum starts at zero, and each term in the series is added to this running total. This is a common pattern in many programming problems.

Program in the Java language :

Here is a Java code snippet that calculates the sum of the series 1^1+2^2+3^3... up to n terms:

public class Main {
    public static void main(String[] args) {
        System.out.println(sumOfSeries(4));  // Output: 288
    }

    public static int sumOfSeries(int n) {
        int sum = 0;
        for (int i = 1; i <= n; i++) {
            sum += Math.pow(i, i);
        }
        return sum;
    }
}

Output:

In this code, we create a sumOfSeries function that takes an integer n as an argument and returns the sum of the series up to n terms. Inside the function, we initialize a sum variable to 0. Then, we create a for loop that iterates from 1 to n. On each iteration, we add the ith term of the series (calculated as i raised to the power of i using Math.pow(i, i)) to sum. After the loop ends, we return the sum. In the main method, we call sumOfSeries(4) to calculate the sum of the first 4 terms of the series and print the result, which is 288.

Program in the C language :

Here is a C code snippet that does the same:

#include <stdio.h>
#include <math.h>

int sumOfSeries(int n) {
    int sum = 0;
    for (int i = 1; i <= n; i++) {
        sum += pow(i, i);
    }
    return sum;
}

int main() {
    printf("%d\\n", sumOfSeries(3));  // Output: 32
    return 0;
}

Output :

In this C code, we define a function sumOfSeries just like in the Java example. The pow function from the math.h library is used to calculate each term of the series. The printf function is used in the main function to print the result of sumOfSeries(3), which calculates the sum of the first 3 terms of the series and gives the output 32.

Tip: When implementing the logic for the series in your chosen programming language, remember to start your loop from 1, not 0 because the first term of the series is 1^1. Also, ensure that your loop runs up to and includes n, the number of terms you want to calculate, as the last term is also part of the series.

Note: The program is designed to calculate the sum of the series 1^1+2^2+3^3... for positive integer values of `n`. If a negative number is given as input, the program's behavior is undefined and it may not function as expected. Additionally, as `n` increases, each term in the series (which is raised to the power of itself) can become very large. This can lead to overflow errors, meaning the calculated value is too large to be represented by the data type being used. For handling large values of `n`, you might need to use a data type that can store very large numbers, or implement an algorithm that can handle such computations without causing overflow.

FAQ
1. What are some real-world applications of this series?
Ans. While this series is primarily of mathematical interest, understanding how to compute series like this one can have practical applications in fields such as computer science, engineering, and physics. They can help in understanding algorithms, solving differential equations, or analyzing complex systems.

2. Why does the series start at 1^1 and not 0^0?
Ans. The series starts at 1^1 because 0^0 is an indeterminate form. That means it's not well-defined and could potentially take on any value, depending on the context. To keep things simple and avoid confusion, we start the series at 1^1.

3. What happens if I try to calculate the series for a very large number?
Ans. If you try to calculate the series for a very large number, you might encounter overflow errors, meaning the calculated value is too large to be represented by the data type being used. This is because each term in the series is raised to the power of itself, which can lead to very large numbers even for relatively small terms. Therefore, when working with large numbers, it's important to consider using data types that can handle them.

Conclusion :

In conclusion, this tutorial has provided a comprehensive guide on how to write a program to calculate the sum of the series 1^1+2^2+3^3... in Python, Java, and C. We've explored the significance of this series in mathematical and computational contexts and unpacked a step-by-step approach to solving it. We've also presented Python, Java, and C code snippets as practical examples. As we explored these solutions, we highlighted the importance of correctly implementing the logic for raising each term to its own power and the need to be cautious of the range of values your program can handle to prevent overflow errors. While this series is primarily of mathematical interest, the ability to compute series like this one has practical applications in various fields and helps us understand complex algorithms.

Sbor - Project Manager for C

Fri, 31 Oct 2025 17:03:44 +0000

Hi devs,

Ever thought that writing CMake at 3am was tedious, you might have read about a project creating script in my previous blog. That script was for not just C, it was for multiple languages.

sbor is a project manager for C which is inspired by cargo. It provides familiar commands like

sbor init to create a new C project which uses CMake to create the Makefile.

sbor build, builds th ebinary using CMake and make

sbor run builds and runs the binary.

sbor add <header> adds a system header like string.h or math.h

sbor remove <header removes the header.

I hope this helps create a better experience for eith Rust devs using C (Not gonna happen I know) and/or beginners to C.

Here is the link

Link

Hello World! Welcome to the C/C++ Group!

Fri, 26 Sep 2025 03:55:41 +0000

Hello World! Welcome to the C/C++ Group!

We’re excited to have you here! This is a space where you can share, learn, and connect with other developers who love C/C++.

Start by saying hi!

Introduce yourself in the comments below—tell us your name, what you’re working on, or something fun about yourself. We’d love to get to know you!

Once you’ve said hi, you can:

Share your C/C++ tips or interesting projects.

Ask questions and get feedback from the community.

Comment on and support other members’ posts.

We’re happy you joined the C/C++ Group and can’t wait to see your contributions. Let’s make this a friendly and helpful place to learn together!

PHardwareITK - Python Module (AkshuDev)

Fri, 11 Jul 2025 19:37:45 +0000

I'm 14 and Built a Python Hardware Interface Toolkit (Yes, It Works)

Hi, I’m AkshuDev (Can't disclose my name) — I’m 14 years old, and over the last 5 months, I built a full hardware interface, OS toolkit, and virtual BIOS in pure Python.

No C. (Unless u like opengl, but I don't provide it in publishes)
No ctypes. (Okay a little bit)
No dependencies (unless you want them).
Just Python.

And it’s live on GitHub and PyPI.

What I Built

PHardwareITK: Phoenix Hardware Interface Toolkit

This module is a complete system for:

File systems (PBFS: Phoenix Block File System)
Virtual CPUs (PVCPU, runs .vasm files)
Memory simulation
BIOS interrupts and booting logic
️ GUI rendering using pure Python (no SDL2 required)
HGame: my own graphics engine inspired by pygame, but written from scratch
Permission management
Tools for OS builders and experimenters
C emulation in Python
And way way more

And the best part, it has 0 required Dependencies, YEAH 0! There are 4 optional Dependencies but required are 0

Here’s the GitHub repo:
PHardwareITK on GitHub

And it’s installable on PyPI:

pip install phardwareitk

How It All Started

My first module was PheonixAppAPI. It was a simple binary + cryptography module I built to support my app, Pheonix.

Then I went to my hometown for a while and didn’t have my PC. I got bored.

So I thought:
“What if I make something that lets Python control hardware?”

And that’s how PHardwareITK was born — from a simple idea to now a 12,000-download module.

How It Works

I wrote my own:

BIOS (in Python)

File system (PBFS)

Bootloader logic

Virtual assembly (.vasm) file format (planned)

Virtual CPU architecture (PVCPU) (in development)

Permission tables, RAM cache, and direct drive access

GUI toolkit using just Python (or optional SDL2 if devs want it)

And a million more things (not really million btw)

Note: PBFS was first made in python and is also called Python Based File System but the official (again by me) is called Pheonix-Block-File-System and I am currently updating that so my current PBFS in this module has outdated layout and will be updated, here check it out -

https://github.com/AkshuDev/Pheonix-Block-File-System

I Even Made a YouTube Video

I created a 4K video showing how PhoenixAppAPI works, including deep binary mapping and encryption tools. You can watch it on this channel-> AkshobhyaEverything

I'm Looking for Contributors

This is a HUGE project — I lost count of how many files it has

I’m currently working on docs, and I’ve tagged some help wanted issues on GitHub. I’d love if you could:

Try it out

Star the repo if you like it ⭐

Help with documentation or examples

Share feedback

It’s open source and 100% Python!

Final Thoughts

If you’re:

An OS dev

A retro computing fan

A Python developer who wants more control

Or just someone curious how a 14-year-old built an entire OS environment in Python...

Come check it out!

Thanks for reading,
— AkshuDev

PHardwareITK - Python Module

Thu, 10 Jul 2025 15:06:58 +0000

I'm 14 and Built a Python Hardware Interface Toolkit (Yes, It Works)

Hi, I’m AkshuDev (Can't disclose my name) — I’m 14 years old, and over the last 5 months, I built a full hardware interface, OS toolkit, and virtual BIOS in pure Python.

No C. (Unless u like opengl, but I don't provide it in publishes)
No ctypes. (Okay a little bit)
No dependencies (unless you want them).
Just Python.

And it’s live on GitHub and PyPI.

What I Built

PHardwareITK: Phoenix Hardware Interface Toolkit

This module is a complete system for:

File systems (PBFS: Phoenix Block File System)
Virtual CPUs (PVCPU, runs .vasm files)
Memory simulation
BIOS interrupts and booting logic
️ GUI rendering using pure Python (no SDL2 required)
HGame: my own graphics engine inspired by pygame, but written from scratch
Permission management
Tools for OS builders and experimenters
And way way more

Here’s the GitHub repo:
PHardwareITK on GitHub

And it’s installable on PyPI:

pip install phardwareitk

How It All Started

My first module was PheonixAppAPI. It was a simple binary + cryptography module I built to support my app, Pheonix.

Then I went to my hometown for a while and didn’t have my PC. I got bored.

So I thought:
“What if I make something that lets Python control hardware?”

And that’s how PHardwareITK was born — from a simple idea to now a 12,000-download module.

How It Works

I wrote my own:

BIOS (in Python)

File system (PBFS)

Bootloader logic

Virtual assembly (.vasm) file format (planned)

Virtual CPU architecture (PVCPU) (in development)

Permission tables, RAM cache, and direct drive access

GUI toolkit using just Python (or optional SDL2 if devs want it)

And a million more things (not really million btw)

https://github.com/AkshuDev/Pheonix-Block-File-System

I Even Made a YouTube Video

I created a 4K video showing how PhoenixAppAPI works, including deep binary mapping and encryption tools. You can watch it on this channel-> AkshobhyaEverything

I'm Looking for Contributors

This is a HUGE project — I lost count of how many files it has

I’m currently working on docs, and I’ve tagged some help wanted issues on GitHub. I’d love if you could:

Try it out

Star the repo if you like it ⭐

Help with documentation or examples

Share feedback

It’s open source and 100% Python!

Final Thoughts

If you’re:

An OS dev

A retro computing fan

A Python developer who wants more control

Or just someone curious how a 14-year-old built an entire OS environment in Python...

Come check it out!

Thanks for reading,
— AkshuDev

Transitioning from Assembly to C: Challenges and Solutions for Programmers Effectively

Sun, 22 Jun 2025 05:46:57 +0000

The Evolution of Programming: From Assembly to C

The history of programming is marked by significant milestones, one of which is the transition from assembly language to C. This shift revolutionized the way programmers wrote code, enabling them to create more portable, maintainable, and efficient software. However, this transition was not without its challenges. Programmers had to adapt to a new language, syntax, and programming paradigm, overcoming obstacles that arose from the differences between assembly language and C.

The early days of programming were characterized by the use of assembly languages, which were symbolic representations of machine code. Assembly languages were closely tied to the hardware architecture, requiring programmers to manually manage registers, memory, and other hardware resources. This low-level programming paradigm demanded a deep understanding of the underlying hardware and its intricacies. Assembly language programming was tedious, time-consuming, and often resulted in code that was difficult to maintain and port.

As programming evolved, the need for a higher-level language became apparent. C, developed by Dennis Ritchie in the early 1970s, marked a significant departure from assembly language. It introduced a higher-level abstraction, allowing programmers to write code that was more portable, efficient, and easier to maintain. C's syntax and semantics were designed to be more intuitive and expressive than assembly language, making it easier for programmers to write complex programs.

Assembly Language: A Low-Level Programming Paradigm

Assembly languages are low-level programming languages that are symbolic representations of machine code. They are closely tied to the hardware architecture, requiring programmers to manually manage registers, memory, and other hardware resources. This low-level programming paradigm demands a deep understanding of the underlying hardware and its intricacies.

Programmers working with assembly language had to be familiar with the specific hardware architecture they were working with. They had to understand the instruction set, register layout, and memory organization of the target machine. This knowledge was essential to write efficient and correct assembly code.

Assembly language programming was tedious and time-consuming. Programmers had to manually manage memory, registers, and other hardware resources, which made it prone to errors. The code was also difficult to maintain and port, as it was closely tied to the specific hardware architecture.

The Advent of C: A Higher-Level Abstraction

C, developed by Dennis Ritchie in the early 1970s, marked a significant departure from assembly language. It introduced a higher-level abstraction, allowing programmers to write code that was more portable, efficient, and easier to maintain. C's syntax and semantics were designed to be more intuitive and expressive than assembly language, making it easier for programmers to write complex programs.

C's higher-level abstraction was achieved through several key features. Firstly, C introduced a type system, which allowed programmers to define the type of variables and functions. This helped catch type-related errors at compile-time, making the code more robust and maintainable.

Secondly, C provided a range of control structures, such as if-else statements, loops, and functions, which made it easier to write structured code. These control structures allowed programmers to write more modular and reusable code, reducing the complexity of large programs.

Thirdly, C introduced pointers, which allowed programmers to manipulate memory addresses directly. Pointers were a powerful feature that enabled programmers to write efficient and flexible code. However, they also introduced new challenges, such as pointer arithmetic and type checking.

Challenges When Transitioning from Assembly to C

When programmers transitioned from assembly language to C, they faced several challenges. One of the primary difficulties was adapting to C's syntax and semantics, which were significantly different from those of assembly language. C's use of pointers, in particular, proved to be a major hurdle for many programmers.

Understanding Pointer Syntax and Semantics

C's pointer syntax can be confusing, especially for those familiar with assembly language, where memory addresses are often manipulated using registers and explicit memory access instructions. In C, pointers are variables that hold memory addresses, and their syntax (e.g., *, &, ->) requires a good understanding of the language's type system and operator precedence.

Programmers had to learn how to declare, initialize, and use pointers correctly, avoiding common pitfalls like null pointer dereferences and pointer arithmetic errors. They had to understand the difference between pointer declaration and pointer dereferencing, as well as the implications of pointer arithmetic.

Pointer Arithmetic and Array Indexing

C's pointer arithmetic and array indexing rules can be tricky to grasp, especially for programmers accustomed to assembly language's direct memory access. Understanding how pointer arithmetic works, and how it relates to array indexing, required a significant mental adjustment.

Programmers had to learn how to use pointer arithmetic to traverse arrays and manipulate data structures, while avoiding issues like buffer overflows and out-of-bounds access. They had to understand the relationship between pointers and arrays, as well as the implications of pointer arithmetic on array indexing.

Type Checking and Casting

C is a statically typed language, which means it checks the types of variables at compile-time. However, C's type system is not as strict as some other languages, and implicit casting can sometimes lead to issues. Programmers coming from assembly language, where type checking is typically not present, had to adapt to C's type system and learn when to use explicit casting.

They had to understand the implications of implicit casting and how to avoid type-related errors. They also had to learn how to use explicit casting to convert between different types, while avoiding potential pitfalls like data loss or corruption.

Other Challenges: Memory Management and Portability

In addition to pointer-related challenges, programmers transitioning from assembly language to C faced other difficulties. One of the most significant was memory management. C provides some abstractions, but it still requires manual memory management using malloc, free, and other functions.

Programmers had to learn how to manage memory effectively, avoiding issues like memory leaks and dangling pointers. They had to understand the implications of dynamic memory allocation and how to use it correctly.

Another challenge was portability. C is a portable language, but different compilers and platforms can have varying implementations and quirks. Programmers had to learn how to write portable code and understand the implications of compiler-specific features and extensions.

Overcoming the Challenges: Practice, Mentorship, and Resources

To overcome the challenges associated with transitioning from assembly language to C, programmers relied on various resources and strategies. One of the most effective ways to learn C was through practice and experience. As programmers wrote more C code, they became more comfortable with the language and its subtleties.

Mentorship and code review also played a crucial role in helping programmers adapt to C. Experienced C programmers helped newcomers learn best practices and avoid common pitfalls. Code review, in particular, was an effective way to identify and fix errors, improving overall code quality.

C textbooks and documentation were another essential resource for programmers. Classics like Kernighan and Ritchie's "The C Programming Language" (1978) and compiler documentation helped programmers learn C and its idioms. Online resources, forums, and communities also provided a wealth of information and support for programmers transitioning to C.

Best Practices for Transitioning to C

To ensure a smooth transition from assembly language to C, programmers can follow several best practices:

Start with the basics: Understand C's syntax, semantics, and type system before diving into complex programs.
Practice, practice, practice: Write C code regularly to become comfortable with the language and its subtleties.
Use resources and documentation: Leverage C textbooks, documentation, and online resources to learn C and stay up-to-date with best practices.
Join online communities: Participate in online forums and communities to connect with other C programmers and learn from their experiences.
Code review and testing: Regularly review and test code to identify and fix errors, improving overall code quality.

Advanced Topics in C Programming

Once programmers have a solid grasp of C's basics, they can move on to more advanced topics. These include:

Advanced pointer manipulation: Understanding how to use pointers to manipulate complex data structures, such as linked lists and trees.
Dynamic memory allocation: Learning how to use malloc, free, and other functions to manage memory dynamically.
Multi-threading and concurrency: Understanding how to write concurrent programs using C's threading APIs.
Advanced data structures and algorithms: Learning how to implement complex data structures, such as hash tables and graphs, and algorithms, such as sorting and searching.

Conclusion

The transition from assembly language to C was a significant milestone in the history of programming. While challenging, this shift enabled programmers to write more portable, maintainable, and efficient code. By understanding the challenges associated with transitioning to C and following best practices, programmers can ensure a smooth transition and become proficient in this powerful and versatile language.

As programming continues to evolve, the lessons learned from this transition remain relevant, informing the development of new languages and programming paradigms. The legacy of C continues to shape the programming landscape, influencing the design of modern languages and software systems.

Future Directions

As programming continues to evolve, it is likely that new challenges and opportunities will arise. The development of new languages, frameworks, and tools will continue to shape the programming landscape. By understanding the history and challenges associated with transitioning to C, programmers can better navigate these changes and adapt to new technologies.

The rise of new programming paradigms, such as functional programming and concurrency, will continue to influence the development of programming languages. Programmers will need to adapt to these new paradigms and learn how to apply them effectively in their work.

In conclusion, the transition from assembly language to C was a pivotal moment in the history of programming. By understanding the challenges associated with this transition and following best practices, programmers can ensure a smooth transition to C and become proficient in this powerful and versatile language. As programming continues to evolve, the lessons learned from this transition will remain relevant, informing the development of new languages and programming paradigms.

The Legacy of C

C's impact on the programming world cannot be overstated. It has influenced the development of numerous other languages, including C++, Java, and Python. C's portability, efficiency, and flexibility have made it a popular choice for systems programming, embedded systems, and other applications where performance is critical.

C's legacy continues to shape the programming landscape, influencing the design of modern languages and software systems. Its influence can be seen in the design of operating systems, compilers, and other low-level software.

In conclusion, the transition from assembly language to C was a significant milestone in the history of programming. While challenging, this shift enabled programmers to write more portable, maintainable, and efficient code. By understanding the challenges associated with transitioning to C and following best practices, programmers can ensure a smooth transition and become proficient in this powerful and versatile language.

Zig Programming Language

Tue, 14 Jan 2025 20:06:06 +0000

In the vast landscape of programming languages, where each claims to solve unique problems, Zig has emerged as a rising star in the systems programming domain. Created by Andrew Kelley in 2016, Zig is a general-purpose programming language that emphasises simplicity, performance, and reliability. For those seeking an alternative to C and C++ for systems-level development, Zig offers compelling features that make it worth exploring.

What is Zig?

Zig is a statically-typed programming language designed to be a better tool for building robust and efficient software. It is particularly suited for low-level programming, such as operating systems, game engines, and embedded systems. Zig’s design philosophy focuses on:

Simplicity: Reducing developer overhead by offering a clean, minimalistic syntax.

Performance: Compiling to highly optimised machine code with predictable execution.

Reliability: Providing strong safety guarantees without sacrificing control over the hardware.

Key Features of Zig

No Hidden Control Flow
Unlike languages that abstract away control flow behind constructs like exceptions, Zig makes control flow explicit. This eliminates surprises and ensures that developers have full control over the program’s behaviour.
Manual Memory Management
Zig gives developers full control over memory allocation and deallocation. While this requires more effort, it prevents the pitfalls of automatic garbage collection and allows precise tuning for performance-critical applications.
Error Handling Done Right
Zig introduces a unique error handling model that replaces exceptions with error unions. Errors in Zig are treated as data, making it easier to reason about failure states and handle them predictably.
Cross-Compilation Made Easy
Zig’s build system and cross-compilation support are second to none. By leveraging LLVM under the hood, Zig can target multiple architectures seamlessly. This makes it an ideal choice for projects requiring portability.
Interop with C
Zig was designed to coexist with C code. Developers can call C functions directly and include C headers without additional bindings. This makes Zig a practical choice for gradually migrating legacy codebases.
Safety and Debugging Tools
Zig offers various safety features like bounds checking, undefined behavior detection, and thread safety without compromising performance. These tools are invaluable for writing reliable software.

Why Choose Zig?

Modern Replacement for C
C has been the go-to language for systems programming for decades, but its lack of modern features can hinder productivity and lead to subtle bugs. Zig retains the power of C while improving safety, readability, and developer experience.
Lightweight and Fast
Zig’s compiler is lightweight and fast, making it easy to integrate into existing workflows. Unlike some languages that require extensive tooling, Zig priorities simplicity and speed.
Growing Ecosystem
Though still relatively new, Zig’s ecosystem is expanding rapidly. Libraries, tools, and community contributions are steadily increasing, making it easier to adopt Zig for real-world projects.
Ideal for Learning Systems Programming
Zig’s explicit nature and lack of hidden abstractions make it an excellent choice for developers who want to deepen their understanding of how computers work at a low level.

Use Cases for Zig

Zig is particularly well-suited for:

Game Development: Its performance and control over memory make it ideal for building game engines and high-performance gaming applications.

Embedded Systems: Zig’s lightweight nature and ability to cross-compile to various architectures make it a natural choice for embedded programming.

Operating Systems: Zig’s low-level capabilities and explicit control over hardware resources enable the development of operating systems and kernels.

Tooling and Compilers: The language’s simplicity and performance are perfect for creating tools like compilers, debuggers, and build systems.

The Future of Zig

As Zig continues to mature, its potential to disrupt the systems programming space becomes increasingly apparent. With each release, new features and optimisations make it an even more attractive choice for developers. While it may not yet rival the popularity of C or Rust, Zig’s unique approach and growing community suggest that it has a bright future ahead.

Conclusion

Zig represents a fresh perspective in systems programming, blending the best aspects of C with modern language features and tooling. Whether you’re building a high-performance application or exploring systems-level programming for the first time, Zig is worth considering. Its emphasis on simplicity, performance, and reliability positions it as a strong contender for the next generation of systems programming languages.

Munmap_chunk() invalid pointer Fixed

Sat, 09 Sep 2023 00:41:08 +0000

The "Munmap_chunk(): Invalid Pointer" error typically appears during the runtime of a program while executing it. It arises when a program tries to free a particular memory portion that has either never been allocated or has already been freed. To resolve this error we need to be careful with memory management , and in this article, we will discuss the error cases deeply and how to resolve them.

Understanding the Error

The "munmap_chunk(): invalid pointer" error typically occurs when there's an attempt to free a pointer that was not allocated through malloc, calloc, or realloc functions, or if the pointer has already been freed. In simpler terms, this error arises when you're trying to return memory that wasn't yours to begin with or no longer belongs to you.

This error can also occur due to buffer overflow, where your program writes more data into a buffer than it can hold, thus overwriting other information. Additionally, it can be caused by memory corruption, where your program erroneously alters the metadata that the dynamic memory allocator uses to keep track of allocated blocks.

Error Triggering Cases

Case 1: Invalid Pointer

In this case we are trying to free a pointer that is not assigned to anything. We only delcared the pointer but didn't define it by intialzing it or assigning a memory address to it. Take a look at the following code:

#include <stdlib.h>

int main(void)
{
        char *ptr; // this is the line that causes the error to happen
        int toallocate = 0;

        if (toallocate)
        {
                ptr = malloc(10);
                free(ptr);
        }
        free(ptr); //This is the line that raises the error

        return 0;
}

Here, we have declared a pointer "ptr", then we are checking with an if condition if it's the right situation to allocate memory and assign the address to "ptr", and after that we called the free function to free the allocated memory

Case 2: Double Free

In this case, we are freeing a memory that we already have freed before and that happens more in complicated programs with a lot of files and modules, so let's check a simple snippet code:

#include <stdlib.h>

int main(void)
{
    char *ptr = malloc(10);
    int isallocate = 0;

    // some code here

    free(ptr); // Correctly freeing the pointer.

    // some other code

    if (isallocate)
        ptr = malloc(15);

    free(ptr); // freeing the ptr again 

    return 0;
}

Of course, it won't be as simple as the above code, but I made it simple to understand it easier and I can assure you it will be the same flow every time. So in the above code, we allocated a memory for some reason, We finished using it and we decided to free it, with no problems till now, but what if we tried it to free the same pointer again ?. That will trigger the error because we can't free a pointer that is already freed.

Case 3: Freeing Part of Allocated Memory

We can't free just a portion of a block of memory. It's all or nothing. So we shouldn't pass a pointer pointing at a memory address other than the one that the memory block starts with. The following code demonstrate the case and where is the line that causes the error:

#include <stdlib.h>

int main(void)
{
    char *ptr = malloc(50); // Allocate memory

    free(ptr + 10); // This line triggers the error
    return 0;
}

So what's happening here? We're allocating a block of memory for ptr using malloc(). Then, we're trying to free() a part of that memory block. Specifically, we are trying to free the memory block after its strating byte by 10 more bytes, but that won't work, because it's to free all the block code or nothing from it, so that will trigger the error.

Walking Through The Solutions

Review Your Code

Start by thoroughly reviewing your code, especially areas where you're freeing memory. Ensure that every pointer you're attempting to free was indeed allocated using malloc, calloc, or realloc. Also, check to make sure you're not freeing the same pointer twice.

char* ptr = malloc(10);
// ... some code ..
free(ptr);
// ... some more code ...
free(ptr); // this will cause an error

In the example above, the pointer ptr is freed twice, which will lead to the "munmap_chunk(): invalid pointer" error.

Debug Your Code

Debugging your code can help identify problematic sections. Tools like Valgrind or GDB (GNU Debugger) are extremely helpful for this purpose.

Valgrind is a programming tool that helps detect memory leaks and memory management issues. Running your program through Valgrind can help pinpoint the exact location of the error:

valgrind ./your_program

Tip: Use the -g option when you compile the code to get useful info like which line that caused the error

GDB is another powerful debugging tool that allows you to see what is going on 'inside' your program while it executes.

gdb your_program
run

Case 1: Solution: Invalid Pointer

In this case, we need to initialize the "ptr" with NULL and that will make it safe to pass it to the free() function without raising any errors unless the program entered the if block, allocated a memory block, and then calling the free two times with same pointer, which will take us to next case and the solution for Double free.

The invalid pointer fix will be like the following code:

#include <stdlib.h>

int main(void)
{
        char *ptr = NULL; // fixed line
        int allocate = 0;

        if (allocate)
        {
                ptr = malloc(10);
                free(ptr);
        }
        free(ptr);

        return 0;
}

Case 2: Solution: Double Free

In the case, we need to assign NULL to "ptr" after calling the free() so if there is any additional attempt to free "ptr", it will run safely without any problems. So the code after the fix will be like the following:

#include <stdlib.h>

int main(void)
{
    char *ptr = malloc(10);
    int isallocate = 0;

    // some code here

    free(ptr); // Correctly freeing the pointer.
    ptr = NULL; // fixed line

    // some other code

    if (isallocate)
        ptr = malloc(15);

    free(ptr); // freeing the ptr again but safely this time

    return 0;
}

Tip: Always after freeing a pointer, assign NULL to the pointer to avoid problems if there is any additional attempts to free the same pointer

Case 3: Solution: Freeing Part of Allocated Memory

In this case, it's obvious that the solution is not to pass a random memory address of memory block or a pointer pointing at a random memory address of the memory block, but the correct method is to pass the memory address that begins the memory block or the pointer that pointing at it, and we get it as the return value of functions that allocate memory dynamiclly like malloc, alloc, etc...the

So the code after the fix should be like the following:

#include <stdlib.h>
int main(void) {
    char *ptr = malloc(50); // Allocate memory

    free(ptr); // Fixed to pass the first of the block memory
    return 0;
}

Fix Buffer Overflows and Memory Corruption

If the error persists even after ensuring correct memory allocation and deallocation, you might be dealing with a buffer overflow or memory corruption.

In case of a buffer overflow, ensure that you're not writing beyond the memory you've allocated. For instance, if you've allocated an array of size 10, make sure you're not trying to access or modify the 11th element.

For memory corruption, the solution is trickier as it involves understanding how dynamic memory management works in C. However, tools like Valgrind can help identify memory corruption issues as well.

It's a good practice to always check the return value of the dynamic allocations functions, like malloc before using it to handle the failure if you are out of memory, you shouldexit the program with a user-friendly error message. better than continue running the program until it crashes, so instead of the following code:

ptr = malloc(10);

// doing something with ptr

We write it correctly like:

ptr = malloc(10);
if (ptr == NULL)
{
   fprintf(stderr, "allocating failed: out of memory");
   exit(1);
}

// doing something with ptr

In the above code, we checked if ptr is NULL. If that condition is true which means that malloc failed to allocate memory, then we print a message to the standard error and exit with 1 which means somethinng wrong happened caused to exit.

Conclusion

In conclusion, while the "munmap_chunk(): invalid pointer" error can initially seem daunting, understanding its root causes and knowing how to debug your code effectively can take you a long way in resolving it.

We have discussed the importance of reviewing the code and using tools to help us like Valgrind and GDB, how to nullish the pointer after freeing it to avoid any potential errors, to pass to the free function the start of the memory block only, and the correct way to handle the failing of allocating memory dynamically. Watch out for buffer overflows, and use tools like Valgrind and GDB to help you along the way. Happy coding!

Assignment makes integer from pointer without a cast in c

Mon, 21 Aug 2023 20:17:46 +0000

Programming can be both rewarding and challenging. You work hard on your code, and just when it seems to be functioning perfectly, an error message pops up on your screen, leaving you frustrated and clueless about what went wrong. One common error that programmers encounter is the "Assignment makes integer from pointer without a cast" error in C.

This error occurs when you try to assign a value from a pointer variable to an integer variable without properly casting it. To fix this error, you need to make sure that you cast the pointer value to the appropriate data type before assigning it to an integer variable. In this article, we will dive deeper into the causes of this error and provide you with solutions to overcome it.

What makes this error occur?

I will present some cases that triggers that error to occur, and they are all have the same concept, so if you understanded why the failure happens, then you will figure out how to solve all the cases easily.

Case 1: Assignment of a pointer to an integer variable

int main(void)
{
        int *ptr, n1, n2;

        n1 = 2;
        ptr = &n1;
        n2 = ptr; /* Failure in this line */
}

In this simple code we have three variables, an integer pointer "ptr", and two integers "n1" and "n2". We assign 2 to "n1", so far so good, then we assign the address of "n2" to "ptr" which is the suitable storing data type for a pointer, so no problems untill now, till we get to this line "n2 = ptr" when we try to assign "ptr" which is a memory address to "n2" that needs to store an integer data type because it's not a pointer.

Case 2: Returning a Pointer from a Function that Should Return an Integer

int* getinteger() {
    int *intp, myint = 10;

    intp = &myint;
    return intp;
}

int main(void)
{
        int result = getinteger(); /* this line causes the failure */

        return (0);
}

As you can see, it's another situation but it's the same idea which causes the compilation error. We are trying here to assign the return of getinteger function which is a pointer that conatains a memory address to the result variable that is an int type which needs an integer

Case 3: Misusing Array Names as Pointers

int main(void)
{
        int myarray[5] = {1, 2, 3, 4, 5};
        int myint;

        myint = myarray; /* this line will cause the failure */

        return (0);
}

As we might already know, that the identifier (name) of the array is actually a pointer to the array first element memory address, so it's a pointer after all, and assigning a pointer type to int type causes the same compilation error.

The solutions

The key to avoiding the error is understanding that pointers and integers are different types of variables in C. Pointers hold memory addresses, while integers hold numeric values. We can use either casting, dereferencing the pointer or just redesign another solution for the problem we are working on that allows the two types to be the same. It all depending on the situation.

Let's try to solve the above cases:

Case 1: Solution: Deferencing the pointer

We need in this case to asssign an int type to "n2" not a pointer or memory address, so how do we get the value of the variable that the pointer "ptr" pointing to? We get it by deferencing the pointer, so the code after the fix will be like the following:

int main(void)
{
        int *ptr, n1, n2;

        n1 = 2;
        ptr = &n1;
        n2 = *ptr; /* Line fixed */
}

Case 2: Solution: Choosing the right data type

In this case we have two options, either we change the getinteger returning type to int or change the result variable type to a pointer. I will go with the latter option, because there are a lot of functions in the C standard library that returning a pointer, so what we can control is our variable that takes the function return. So the code after the fix will be like the following:

int* getinteger() {
    int *intp, myint = 10;

    intp = &myint;
    return intp;
}

int main(void)
{
        int *result = getinteger(); /* Fixed line */

        return (0);
}

We here changed the result variable from normal int to an int pointer by adding "*".

Case 3: Solution: Using the array subscript operator

In this case we can get the value of any number in the array by using the subscript opeartor ([]) on the array with the index number like: myarray[1] for the second element which is 2. If we still remember that the array identifier is a pointer to the array first memory, then we can also get the value of the array first element by deferencing the array identifier like: *myarray which will get us 1.

But let's solve the case by using the subscript opeartor which is the more obvious way. So the code will be like the following:

int main(void)
{
        int myarray[5] = {1, 2, 3, 4, 5};
        int myint;

        myint = myarray[0]; /* Fixed line */

        return (0);
}

Now the number 1 is assigned to myint without any compilation erros.

The conclusion

In conclusion, the error "assignment to ‘int’ from ‘int *’ makes integer from pointer without a cast" arises in C programming when there is an attempt to assign a memory address (held by a pointer) directly to an integer variable. This is a type mismatch as pointers and integers are fundamentally different types of variables in C.

To avoid or correct this error, programmers need to ensure they are handling pointers and integers appropriately. If the intent is to assign the value pointed by a pointer to an integer, dereferencing should be used. If a function is meant to return an integer, it should not return a pointer. When dealing with arrays, remember that the array name behaves like a pointer to the first element, not an individual element of the array.

Coder Legion - Recent posts tagged c

Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine

Ternary Semantic Brain Core — Zero Hard-Coding, Language-Independent Meaning Engine

What makes it different

How it works

Architecture

Results (65 books trained)

Cross-Language Bridge Examples

What this is NOT

Try it yourself

The missing break behind Digimon World’s evolution rules

tags: reverseengineering, c, gamedev, cpp

The missing break

The scoring system: four checks, three needed

Care mistakes, and the flag that inverts them

Weight is a window, not a floor

Stats, where the stage changes the rule

The bonus point: any one of five

The rule that quietly steers your collection

Who actually did this

Running their code somewhere it has never run

Measuring the GTE instead of guessing at it

Where I got things wrong

What this does not prove

What we finally understand

My Journey with C++: Building Efficient and Reliable Software

Why I Enjoy Working with C++

What I Focus On

Learning Never Stops

Assembly language

How to Write to Web.config in Medium Trust

Writing a Programming Language & Native x86-64 Compiler from Scratch in C: The Story of Yolish

1. Language Design: Ergonomics Meets Systems Control

Immutability by Default

Pattern Matching with Ranges & Guards

Structs and impl Blocks

2. Bridging Code to the Kernel: First-Class Capabilities

3. The Tri-Engine Architecture: Interpreter, Bytecode VM, and Native Compiler

4. No LLVM, No Bloat: Direct Multi-Platform Binary Emission

5. Runtime Architecture: Mark-and-Sweep Garbage Collection

6. A Tooling-First Philosophy

7. What Writing a Compiler in C Teaches You

Conclusion & Open Source

Building an x86-64 Operating System from Scratch in C: The Exploidus Story

Exploiting "Trust-by-Default": How I transformed an ESP32-S3 into a BadUSB

The architectural choice: Dynamic Parser vs Hardcoding

RAM Security: O(1) Space Complexity

Beyond abstraction: USB Protocol and Polling Rate

State-Based Logic and the Auto-Repeat Trap

Conclusion

C++20 Modules in Practice: From Header Hell to Modular Architecture

Mental Model: The Key Declarations

What a Named Module Actually Is

Building Modules with CMake and Ninja

Interface vs. Implementation Units

Implementation units do not map one-to-one to declarations

Splitting Implementation Across Files

A library, not just an executable

Modules and Legacy Headers

#include in the module purview

The global module fragment

Header units

Migrating a Header-Based Library

Partitions

A sharp edge: implementation partitions

The std Module (C++23)

Compiler, CMake, and IDE Compatibility

What Modules Do Not Solve

Takeaway

Further Reading

GGUF2BIN Custom C99 runtime: GGUF → G2BX → inference (Qwen3 / Qwen2 / Llama).

gguf2bin2 https://github.com/AnonymoDGH/gguf2bin

⚡ Speed

🚀 Quick start

🧠 RAM knobs

What counts against a 2 GB budget?

🎛 CLI

🎮 Dual band CPU+GPU (--gpu)

📐 Quality

Was not declared in this scope c++

Structs and `impl` Blocks

`#include` in the module purview

The `std` Module (C++23)

🎮 Dual band CPU+GPU (`--gpu`)