Checked arithmetic needs an explicit meaning for success

A function named for checked arithmetic still needs a precise account of what its Boolean result means. David Svoboda's N2543, dated July 8 and recorded in the WG14 document log, makes that decision explicitly. In this revision, the proposed core operations return true when the computation is valid. That convention matters to every caller that decides whether it can use the output.

The paper proposes low-level checked arithmetic on ordinary integers, with a supplemental design for checked values. Its scope includes addition, subtraction, and multiplication. It leaves the application responsible for deciding what an unrepresentable result means for the operation being attempted.

I consider that separation useful for C. Detecting an arithmetic error belongs close to the calculation, while deciding whether to reject an input or abandon an operation belongs to the application. A standard facility can make detection available without pretending that every program has the same recovery policy.

The output type is part of the question

The core proposal uses an output pointer followed by the two operands. Its description checks the computation and the conversion into the output type. This makes the destination relevant to the operation's validity, including cases involving truncation or signedness.

The following is illustrative proposed syntax. It belongs to N2543's design and should not be mistaken for an interface already supplied by standard C.

size_t bytes;

if (!ckd_mul(&bytes, count, element_size)) {
    return -1;
}

Here the caller uses the true-on-success convention of this paper. The failure branch prevents the program from treating an invalid result as an acceptable byte count. The example assumes that the surrounding function's contract uses a negative return value for failure.

The important design decision is the relationship between the status and the output. A caller needs to know when the output has the mathematical meaning it expects. Merely receiving a value in the destination object is insufficient, because many bit patterns are possible values without being the intended result.

For a byte count, this distinction affects what can follow. A subsequent allocation or copy needs a count that represents the requested work. A value produced through an invalid calculation cannot establish that requirement, even if it happens to be small enough for the next API.

Detection does not choose a policy

A checked multiplication can tell the caller that its requested result is not representable under the operation's rules. It cannot determine whether the user made a mistake or whether the program should use a different representation. Those questions depend on the purpose of the count.

For example, a request for an impossibly large object may warrant rejection. A numerical algorithm with intentionally bounded values may have a different specified response. The presence of arithmetic checking does not make those decisions interchangeable.

This is why replacing every failed result with a maximum value would be a new application policy. It can change the meaning of a requested operation. Such a policy needs a reason grounded in the application, rather than following automatically from the availability of an error flag.

The same applies to continuing with a stored result after failure. Unless the interface defines a useful meaning for that case and the application wants that meaning, the program has not recovered. It has only carried an invalid intermediate into the next operation.

N2543's low-level approach gives callers a place to make that decision. It does require explicit control flow for calculations whose validity must be checked individually. That cost follows from keeping failure handling visible in ordinary C source.

A compound expression has intermediate requirements

An expression such as a product followed by a sum can fail at an intermediate step. Checking only the final conversion does not necessarily establish that every earlier operation was valid. Each operation has its own inputs and representational limits.

The C working draft describes undefined behavior when an expression's result is outside its type's representable range. The proposed checked operations address the need to detect arithmetic problems without relying on an invalid ordinary expression as the test.

This is especially relevant when the mathematical final result appears reasonable. Intermediate requirements follow the operations the program actually requests. An argument based only on the final mathematical formula can omit those requirements.

The supplemental proposal explores carrying validity with a value so that operations can propagate that information. This changes the ergonomics of composing calculations. A result can retain evidence that an earlier operation failed, even when a later operation would produce an ordinary-looking number.

That design has a practical consequence for interface authors. If a function extracts the numerical part and discards validity, the next caller loses the information the checked representation was intended to preserve. The interface needs to say where checking ends and where ordinary values become acceptable again.

Names do not establish conventions

The proposed ckd_ prefix describes the general subject, but it does not establish Boolean polarity by itself. A reader still has to know whether true means a successful exact result or a detected problem. An application wrapper can introduce another convention, making that detail even more important at boundaries.

I prefer interfaces whose examples show the failure branch directly. The branch demonstrates how the status controls use of the result, which is the operational fact a caller needs. A short signature alone can leave that relationship ambiguous.

The same care applies to error propagation. A helper returning success may need to invert the result of an underlying operation with a different convention. Copying a familiar-looking call into a new wrapper is insufficient unless its condition preserves the intended meaning.

N2543 makes representability a result that the application can inspect. Its proposed core gives ordinary C code explicit operations for the supported arithmetic, while the supplemental design considers how validity can accompany composed values. For a caller computing a byte count, the substantive requirement remains that the successful branch establishes the count before any operation uses it.