Copy 40 bytes into a 32-byte array, and the extra bytes can overwrite adjacent memory. In C++, the compiler often cannot determine whether a copy is safe: a pointer may carry no usable size information, and the input may not arrive until runtime. The safer approach is to make ownership, lengths, and valid states explicit in the code.
Start with ownership and lifetime
Manual allocation leaves you with two obligations: release the resource exactly once, and never use it afterward. Prefer objects tied to a scope. Use std::vector for a growable byte buffer, std::string for owned text, and std::unique_ptr when one object must own a dynamic allocation. Their destructors handle cleanup even if a function returns early or throws.
For example, std::vector<std::byte> buffer(count); owns its storage. A raw pointer from buffer.data() does not; it only points into that storage. If the vector grows or is destroyed, the pointer may become invalid. Keep such views short-lived, and store one only if you can prove its owner will outlive every use. std::span pairs a pointer with a length, but it does not extend the owner's lifetime.
When an API must return an allocated object, return it by value or use a smart pointer with a clear owner. Never return a reference to a local variable. Its lifetime ends when the function returns.
Keep operations within bounds
std::vector and std::string track their lengths, but their operator[] does not check bounds. Use .at(index) if an exception fits the program's error handling; otherwise, check the index before using []. An insertion, erase, or resize can also invalidate iterators, so review any iterator kept across those operations.
Check bounds before forming a pointer or copying data. If an offset and length select part of a buffer, offset + length <= buffer.size() can overflow when the values are unsigned. Check offset <= buffer.size() first, followed by length <= buffer.size() - offset. Form the subrange only after both checks pass.
Prefer destinations whose capacity is known or exposed. Before copying into a fixed-size destination, compare the source length with that capacity. C-style strings need a separate check for the terminator: copying exactly sizeof(destination) bytes leaves no room for ''. If a field is binary data rather than text, store it as bytes and pass its length instead of relying on a terminator.
Treat size calculations as security checks
An untrusted count might pass an initial check yet overflow when multiplied by the size of each element. Before allocating count records, check the application's record limit. Where multiplication is needed, also verify count <= maximum / sizeof(Record). A count can be mathematically valid and still demand too much memory, so set a practical resource limit too.
Watch conversions between signed and unsigned types. Converting a negative integer to std::size_t produces a large positive value. Check that a parsed count is nonnegative before converting it, then compare it with the application's maximum. Within a function, use consistent types for indexes and lengths rather than depending on warnings to catch every mixed-type comparison.
Validate input at the point where its meaning is known
Reading a line without overflowing a buffer does not mean the input is valid. A parser must check syntax, ranges, and relationships between fields before the data controls an allocation or an index. For a file format with a declared payload length, check both that the length meets the application's limit and that enough bytes remain. Reject a truncated record rather than letting a later read work with an incomplete object.
Separate parsing from acting on the result. A parser can return a validated structure or an explicit error; it should not hand the caller a partially initialized object that appears usable. Establish invariants in constructors, and avoid APIs that depend on callers assigning fields in a particular order before an object is safe to use.
Library calls need the same attention. Check documented preconditions: does the API accept empty input, does its length include a terminator, and who owns returned memory? A small C++ wrapper around a difficult C API can keep those checks in one place.
Handle errors without hiding them
Decide what happens when a read, conversion, or allocation fails. After a failed stream extraction, do not continue with an uninitialized value. Use an exception, an error return, or a result type that carries either a value or an error, according to the operation. Make the failure visible to the caller and keep cleanup automatic.
RAII—resource acquisition is initialization—applies beyond memory. A file object closes its file when its lifetime ends; a lock guard releases a mutex on every exit path. Both help when an exception interrupts the normal path. A cleanup destructor should not throw another exception during stack unwinding, which can terminate the program.
Use compiler and test feedback deliberately
Build with a modern C++ language standard and enable useful warnings, including conversion warnings if the codebase can address them. Investigate narrowing, missing returns, and suspicious comparisons instead of treating those warnings as noise. Warnings do not prove code is secure; document the reason when you suppress one.
During development and in authorized test environments, run representative tests with AddressSanitizer and UndefinedBehaviorSanitizer when your compiler supports them. They can catch out-of-bounds access, use-after-free, and some undefined operations on paths the tests execute. They cannot establish that untested paths are safe. Fuzzing a parser with generated input can reveal edge cases, provided you test software you own or have permission to test. When a tool finds a failure, save the smallest input that reproduces it and add a regression test.
Review dependencies and build settings as well. A safe local function may still pass invalid data to an older library or depend on behavior seen only in a debug build. Assertions help document programmer assumptions, but they may be disabled. Use ordinary runtime checks for conditions untrusted input can violate.
A compact review checklist
- Ownership: Can every pointer or view be traced to an owner that remains alive?
- Bounds: Are indexes, offsets, and copy lengths checked before use?
- Arithmetic: Can addition, multiplication, or type conversion change the intended size?
- Input: Are malformed and excessive values rejected before allocation or access?
- Failure: Does every failed operation leave the program in a defined state?
As a first exercise, take a function that reads a length-prefixed record. Test a valid record, a declared length longer than the remaining data, a length above the application's limit, and an empty payload. Define which inputs the format accepts, then check that every rejection produces a clear error rather than a partial record or an attempted oversized allocation.
