Abstract

The single-entry, single-exit (SESE) principle has been an established element of structured programming and safety-oriented software development for several decades. In MISRA C++:2008, this principle was expressed explicitly through Rule 6-6-5, which required every function to have a single point of exit at the end of the function. Consequently, functions containing multiple return statements were considered non-compliant with the rule.

MISRA C++:2023 no longer contains this requirement. The change raises an important question concerning the relationship between the historical SESE principle and its subsequent interpretation in coding standards: why was a rule previously classified as Required removed rather than retained or relaxed?

This paper examines the historical interpretation of SESE, its relationship with structured programming and the modular approach described in IEC 61508, and its codification in MISRA C++:2008. Particular attention is given to the distinction between multiple textual return statements and multiple control-flow exit destinations. In modern C++, several return statements within a function may transfer control to the same destination, namely the caller of the function. Consequently, the number of return statements does not necessarily correspond to the number of exit destinations in the sense originally associated with SESE.

The removal of Rule 6-6-5 can therefore be interpreted as a reconsideration of the relationship between a historical software-engineering principle and a specific syntactic mechanism used to enforce it. This does not imply that unrestricted use of multiple return statements is desirable in safety-critical software. Rather, it suggests that control-flow comprehensibility, analyzability, and verifiability may constitute more meaningful safety properties than the number of textual return statements alone.

Keywords: MISRA C++, MISRA C++:2023, structured programming, single-entry single-exit, SESE, IEC 61508, safety-critical software, control flow, C++, automotive software

1. Introduction

The single-entry, single-exit (SESE) principle has historically been associated with structured programming and the development of software that can be decomposed into comprehensible and analyzable components. In safety-critical software engineering, this principle has also been reflected in several standards and guidelines.

MISRA C++:2008 expressed the principle through Rule 6-6-5:

“A function shall have a single point of exit at the end of the function.”

The rule was classified as Required, which meant that a function containing multiple return statements was considered non-compliant.

This requirement was not carried forward into MISRA C++:2023. The corresponding rule was removed rather than being reclassified as Advisory or otherwise relaxed.

The change is significant because it concerns a principle that had previously been treated as sufficiently important to warrant a mandatory coding requirement. It therefore raises the question of whether the underlying safety argument associated with SESE has changed, or whether the historical interpretation of SESE as a requirement for a single textual return statement was itself too restrictive.

To investigate this question, it is necessary to distinguish between two related but conceptually different properties:

1. the existence of a single control-flow entry and exit destination, and
2. the presence of a single syntactic return statement within a function.

These properties are not necessarily equivalent in a structured programming language such as C++.

2. Historical Origins of Single-Entry, Single-Exit

The conceptual foundations of structured programming predate modern C++ by several decades. Work by Böhm and Jacopini, followed by the development and dissemination of structured-programming principles, contributed to the formalisation of structured control flow. Dijkstra’s work subsequently played an important role in establishing structured programming as a fundamental approach to software development.

A central objective was to replace unrestricted control-flow transfers with a limited set of structured constructs, including:

• sequence,
• selection, and
• iteration.

Such constructs can be represented conceptually as having a well-defined entry and exit:

This approach was particularly relevant in programming environments in which unrestricted control-flow mechanisms were available. A program could, for example, transfer execution into an arbitrary location within a block of code or leave a block through a destination unrelated to its normal control-flow structure.

Consequently, the original motivation for SESE was primarily concerned with the structure of control flow, rather than with the number of occurrences of a particular source-code keyword.

The distinction is important. The original principle can be expressed approximately as requiring a software component to have a well-defined point at which control enters it and a well-defined point at which control leaves it. This is conceptually different from requiring the source code to contain exactly one return statement.

3. The Meaning of “Single Exit”

The distinction between an exit point and a return statement can be illustrated using an unstructured control-flow model:

In such a structure, execution may leave the component through different control-flow destinations. The different exits represent distinct connections between the component and its surrounding environment.

Here is an example of a C code that is using goto, where:
1) foo have 2 entry points (starts from beginning or from the middle label)
2) bar have 2 exit points (even with only return statement) (through the return or go to)

#include <stdio.h>
void *target;
void foo(void)
{
    printf("foo: start\n");
    target = &&middle;
    printf("foo: before middle\n");
middle:
    printf("foo: middle\n");
}
void bar(void)
{
    printf("bar: before jump\n");
    goto *target;   // GCC extension: indirect goto
    printf("bar: after jump\n");
}
int main(void)
{
    foo();
    bar();
    return 0;
}

This situation is fundamentally different from the following C++ function:

Result process(Input input)
{
    if (!input.valid())
    {
        return Result::Invalid;
    }
    if (!ready())
    {
        return Result::NotReady;
    }
    return doWork(input);
}

The function contains three return statements, but all three transfer control to the same external destination: the caller of process.

Conceptually, the control flow can therefore be represented as:

The function consequently has multiple return sites, but not multiple external return destinations.

This distinction is particularly relevant when the historical SESE principle is applied to modern programming languages.

4. From the SESE Principle to Coding Rules

Over time, the SESE principle became increasingly associated with the more concrete requirement that a function should contain a single return statement located at its end.

MISRA C++:2008 represented one such interpretation. Rule 6-6-5 required:

“A function shall have a single point of exit at the end of the function.”

The resulting implementation pattern can be illustrated as follows.

Multiple-return implementation

Result process(Input input)
{
    if (!input.valid())
    {
        return Result::Invalid;
    }
    if (!ready())
    {
        return Result::NotReady;
    }
    return doWork(input);
}

Single-return implementation

Result process(Input input)
{
    Result result;
    if (!input.valid())
    {
        result = Result::Invalid;
    }
    else if (!ready())
    {
        result = Result::NotReady;
    }
    else
    {
        result = doWork(input);
    }
    return result;
}

The second implementation satisfies the syntactic requirement imposed by Rule 6-6-5. However, satisfying this requirement does not necessarily result in a simpler control-flow structure.

The transformation may introduce:

• additional state variables,
• additional conditional branches,
• deeper nesting,
• greater indentation,
• increased distance between the condition determining an error and the point at which the function terminates.

Therefore, the question arises whether a syntactic reduction in the number of return statements necessarily corresponds to a reduction in control-flow complexity.

5. The Relationship with IEC 61508

The SESE principle did not originate with MISRA. It has also been incorporated into safety-oriented software-engineering guidance.

IEC 61508-7:2010, Section C.2.9, Modular approach, discusses the decomposition of software into small and comprehensible components and identifies single entry and single exit among the principles used by a number of development methods.

The modular approach is presented in conjunction with other principles, including:

• assignment of a single, well-defined task to a module;
• limited and strictly defined connections between modules;
• strong cohesion;
• hierarchical decomposition;
• restrictions on module size; and
• defined interfaces.

The underlying objective is the decomposition of a software system into small, comprehensible components in order to limit system complexity.

This context is important because IEC 61508 does not formulate the principle specifically as a requirement that every C++ function contain exactly one return statement. Rather, single entry and single exit appear as part of a broader modularization strategy.

The distinction suggests that the historical safety argument was concerned with module structure and control-flow complexity, rather than with a particular syntactic representation.

6. Codification in MISRA C++:2008

MISRA C++:2008 converted the broader SESE concept into a directly verifiable source-code requirement through Rule 6-6-5.

From a static-analysis perspective, this approach has an obvious advantage: compliance can be determined mechanically by identifying multiple return statements or a return statement that does not occur at the end of the function.

However, the mechanical verifiability of a rule does not establish that the syntactic property being measured is identical to the underlying software-engineering principle.

In particular, the following implication does not necessarily hold:

single return statement
        ↓
single control-flow exit
        ↓
simple control flow
        ↓
easier verification

The first property can be enforced syntactically, while the subsequent properties concern the actual semantics and structure of the program.

This distinction becomes increasingly relevant as programming languages provide stronger abstractions for control flow and resource management.

7. Multiple Returns in Modern C++

A useful way of examining the issue is to consider the control-flow graph rather than the source-code representation.

For example:

Status f(Input input)
{
    if (badInput(input))
        return Status::BadInput;
    if (hardwareFailure())
        return Status::HardwareFailure;
    return Status::Ok;
}

From the perspective of the caller, all three paths terminate at the same destination:

The returned value varies, but the control-flow destination outside the function remains the same.

This differs fundamentally from an unrestricted jump to an arbitrary location in the surrounding program.

Consequently, the presence of multiple return statements should not, by itself, be interpreted as evidence that a function violates the underlying structural objective of SESE.

8. The Reconsideration in MISRA C++:2023

The removal of Rule 6-6-5 from MISRA C++:2023 is consistent with a reconsideration of the historical interpretation of SESE in the context of modern C++.

MISRA C++ committee member Loïc Joly has publicly explained the reasoning behind the change. In response to a question concerning whether MISRA C++:2023 still required a single exit from a function, he stated that it did not. He subsequently explained that the committee had revisited the history of the SESE principle and considered the distinction between structured languages and earlier programming environments.

According to this explanation, the original formulation of single-entry/single-exit predates the widespread adoption of structured programming. In a structured language such as C++, multiple return statements nevertheless lead to a single external destination: the caller of the function.

This interpretation provides a direct explanation for why the former rule was not simply downgraded from Required to Advisory, but removed.

It is important, however, to distinguish between normative evidence and interpretative evidence. The absence of Rule 6-6-5 is a normative characteristic of MISRA C++:2023. The explanation provided by a committee member constitutes publicly available interpretative evidence concerning the rationale for the change; it should not be presented as normative wording contained in the standard itself.

This distinction is particularly relevant when the issue is considered in the context of a safety assessment, compliance argument, or audit.

9. The Relevance of Modern C++ Language Features

The evolution of the C++ language also affects the applicability of historical arguments for a single textual exit.

MISRA C++:2023 targets C++17 and incorporates a substantially revised set of guidelines relative to MISRA C++:2008. Modern C++ provides language mechanisms that reduce the relevance of some traditional arguments for a single textual function exit.

One important example is Resource Acquisition Is Initialization (RAII).

Consider:

void process()
{
    Resource r;
    if (!valid())
        return;
    doWork();
}

When the return statement is executed, the lifetime of the local object r is terminated in accordance with C++ object-lifetime rules. Its destructor is invoked automatically.

Consequently, resource cleanup does not generally depend on execution reaching a specific final statement at the end of the function.

This does not imply that early returns are universally desirable. It does, however, demonstrate that the historical argument that all cleanup must be concentrated at a single textual exit is not directly applicable to modern C++ when resource management is implemented using RAII.

10. Single Return Versus Control-Flow Complexity

The potential difference between syntactic simplicity and structural simplicity can be illustrated using a validation function.

An early-return implementation may be expressed as:

Status validate(const Data& data)
{
    if (!data.headerValid())
        return Status::InvalidHeader;
    if (!data.payloadValid())
        return Status::InvalidPayload;
    if (!data.signatureValid())
        return Status::InvalidSignature;
    return Status::Valid;
}

The resulting control flow is straightforward:

invalid header      → return
invalid payload     → return
invalid signature   → return
otherwise           → success

Applying a single-exit requirement can instead produce:

Status validate(const Data& data)
{
    Status result = Status::Valid;
    if (!data.headerValid())
    {
        result = Status::InvalidHeader;
    }
    else
    {
        if (!data.payloadValid())
        {
            result = Status::InvalidPayload;
        }
        else
        {
            if (!data.signatureValid())
            {
                result = Status::InvalidSignature;
            }
        }
    }
    return result;
}

Although the second implementation contains a single return, it introduces additional nesting and state.

This observation does not establish that early returns are preferable in every case. Rather, it demonstrates that the number of return statements is an imperfect proxy for structural complexity.

The more relevant question is therefore whether the selected control-flow structure facilitates:

• comprehension,
• review,
• static analysis,
• verification,
• testing, and
• demonstration of the intended safety properties.

11. Removal of the Rule Does Not Imply Unrestricted Control Flow

The removal of Rule 6-6-5 should not be interpreted as a rejection of structured programming or as an endorsement of arbitrary control-flow constructs.

MISRA C++:2023 continues to provide guidelines addressing control-flow structure, unreachable code, loops, goto, complexity, and other potentially problematic constructs.

Consequently, the removal of the former single-exit requirement should be interpreted more narrowly:

MISRA C++:2023 no longer treats a single textual exit at the end of every function as a universal requirement for safe C++ programming.

This interpretation differs substantially from the proposition that multiple return statements are inherently desirable.

For example, a function containing numerous early returns, complex side effects, and multiple interacting state transitions may remain difficult to analyse and review. Conversely, a small function containing two straightforward guard clauses may have a simple and readily verifiable control-flow structure.

The relevant property is therefore the actual structure and behaviour of the function, rather than the number of return tokens appearing in its source code.

12. Comparison with MISRA C

The removal of the rule from MISRA C++:2023 should not be generalised to MISRA C.

MISRA C:2023 retains Rule 15.5:

“A function should have a single point of exit at the end”

and classifies it as an Advisory rule.

The current situation can therefore be summarised as follows:

The difference is significant. The fact that MISRA C continues to contain a single-exit guideline demonstrates that the issue has not been universally rejected across the MISRA family of standards.

Instead, the treatment of the principle is language- and guideline-specific.

13. Reassessing MISRA C++:2008

The removal of Rule 6-6-5 should not necessarily be interpreted as evidence that the underlying concerns addressed by the rule were invalid.

Several of those concerns remain relevant to safety-critical software:

• uncontrolled control flow can complicate analysis;
• implicit or non-local control transfers can make program reasoning more difficult;
• side effects may make premature termination hazardous;
• improperly managed resources may lead to incorrect behaviour;
• simpler control-flow structures generally facilitate verification.

The more questionable assumption is that these concerns can be adequately represented by the following syntactic constraint:

Every C++ function shall contain exactly one return statement, and that statement shall occur at the end of the function.

Modern C++ provides structured function invocation, lexical scopes, deterministic object lifetime and RAII. Consequently, multiple return statements do not inherently introduce arbitrary control-flow destinations.

The number of return statements is therefore not, in isolation, a reliable measure of whether a function exhibits the form of multiple exits that the historical SESE principle sought to prevent.

14. Implications for Safety-Critical Automotive C++

For an automotive software project developed according to ISO 26262 and MISRA C++:2023, the absence of Rule 6-6-5 means that a project does not need to prohibit multiple return statements solely on the basis of MISRA C++ compliance.

This does not eliminate the need for project-specific coding guidelines. Instead, project rules can focus on properties that are more directly related to safety and verifiability.

14.1 Control-flow clarity

Simple guard clauses can provide an explicit and readily understandable representation of preconditions:

if (!input)
    return Error;
if (!ready)
    return NotReady;

The control flow is local and explicit.

14.2 Side effects before termination

Greater scrutiny is appropriate when a return follows a state-changing operation:

updateHardware();
if (error)
    return Failure;

The relevant question is not merely whether the return is early, but whether terminating execution at that point is semantically correct with respect to the system state.

14.3 Resource management

Resource lifetime and cleanup should be analyzed according to the C++ object-lifetime model. Where appropriate, RAII can ensure that resources are released independently of the particular return path.

14.4 Function complexity

A large number of return statements may indicate that a function contains excessive responsibilities or complexity. However, introducing a single result variable solely to satisfy a single-exit convention does not necessarily address the underlying problem.

In such cases, functional decomposition may provide a more appropriate solution.

14.5 Verifiability

Ultimately, the central consideration in safety-critical software should be whether the control flow can be adequately understood, analyzed, tested, and verified.

A coding rule that is easy to check mechanically is valuable only when the property being checked is sufficiently correlated with the relevant safety objective.

15. Discussion

The evolution of the single-exit rule illustrates a broader issue in the development and application of software safety standards: the distinction between a software-engineering principle and a specific syntactic mechanism used to enforce that principle.

The historical development can be summarized as:

Structured programming
        ↓
structured control flow
        ↓
single-entry / single-exit constructs
        ↓
IEC 61508 modular approach
        ↓
MISRA C++:2008 Rule 6-6-5
        ↓
single return statement at the end
        ↓
reconsideration in MISRA C++:2023
        ↓
rule removed

This progression demonstrates that a principle can acquire increasingly specific interpretations as it is incorporated into successive standards and coding guidelines.

Such concretization can be beneficial because it enables consistent enforcement and automated analysis. However, it also introduces the possibility that the measurable syntactic property may eventually become decoupled from the underlying end