C Software Development

Inherited C is a reading exercise before it is a coding one. We start with the build: can the program be compiled today, with which compiler and which flags? Then the boundaries: which functions touch memory directly, which files are shared across modules, and where the error handling actually lives. A short map of those areas prevents most accidental damage.

Old code often carries assumptions about integer width, byte order or the size of a pointer. Those assumptions were true on the machine it was written for and may not hold on a current one. We make them explicit before porting, because a silent truncation is much harder to find than a compile error.

Every allocation needs an owner and a lifetime, and that rule belongs in a document rather than in one developer head. We record which function allocates, which one frees, and what happens on an error path. The convention is applied consistently, because mixed ownership is where double frees and leaks begin.

Tooling supports the rule. Address and undefined-behaviour sanitisers catch mistakes during tests, static analysis flags suspicious patterns, and a valgrind run on a representative workload finds leaks that unit tests miss. None of these replace a clear convention, but together they make violations visible early.

A C project is only as portable as its build. We pin the compiler, record the flags, and keep the build in a script that runs from a clean checkout. Warning levels are raised rather than lowered, because a warning suppressed to make a build pass tends to describe a real defect.

Cross-platform work needs more care. GCC, Clang and MSVC differ in their extensions, their headers and their default behaviour. We test on each target that matters and avoid compiler-specific tricks unless the platform requires them. The build instructions are part of the deliverable.

Changing untested C is a gamble. The first task is a harness around the functions that matter, driven by real input files. Characterisation tests record what the program does today, including its quirks, so a later change can be judged against observed behaviour rather than an assumption about intent.

Fuzzing helps for parsers and anything that reads untrusted input. A few hours of random input often finds the boundary condition that a hand-written test suite missed. We keep the corpus so the finding stays fixed.

Often the cheapest fix is not a rewrite but a small C component with a narrow interface. A Python service that spends most of its time in a loop, a .NET tool that needs a fast codec, or a desktop application that stalls on a large file can all call a C library through a stable boundary.

The interface is kept small: a handful of functions, explicit sizes, clear ownership and a documented error code for every failure. That contract lets the host language treat the module as a black box and keeps the unsafe surface auditable.

A port succeeds when the callers do not notice. We keep the public headers stable, preserve behaviour on edge cases and move implementation details behind the interface. Where a signature must change, we add a new function and keep the old one as a wrapper for a release, so dependent teams can migrate on their own schedule.

Endianness, alignment and integer sizes get explicit types rather than the native ones. The result is code that behaves the same on a different machine, which is usually the entire point of the exercise.

We do not claim firmware development, board bring-up, hardware certification or work that depends on a physical device we cannot test. Our C work is software that runs on ordinary computers and servers, delivered from a desk and verified with tests and sanitisers. When a project needs embedded tooling and lab equipment, a specialist firm is the honest recommendation.

A profiler answers the question that benchmarks only hint at. We measure where time goes, then decide whether the fix is algorithmic, a memory layout change or a compiler flag. Micro-optimisation without a measurement is how a codebase becomes unreadable and no faster.