Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Votre message a été envoyé.

Nous vous répondrons à

Si vous n'avez toujours pas reçu de réponse, vérifiez votre dossier
Spam/Junk et cliquez sur le bouton "Not Spam".
De cette façon, vous ne manquerez la réponse de notre équipe.

An example of undefined behavior caused…

An example of undefined behavior caused by absence of return

10 Fév 2022

This article contains a very interesting example. The absence of the return statement in a value-returning function leads to undefined behavior. It's a perfect example of how wrong code can crash one day, even though it could work for many years.


We inspect an error pattern that the SEI CERT C++ coding standard describes as MSC52-CPP. Value-returning functions must return a value from all exit paths.

The C++ Standard, [stmt.return], paragraph 2 [ISO/IEC 14882-2014], states the following: 

Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.

A simple example of code with an error:

int foo(T a, T b)
  if (a < b)
    return -1;
  else if (a > b)
    return 1;

The developer forgot to write return 0 if two values are equal. Not all execution branches return the value, and this leads to undefined behavior.

I think everything's clear here. It's a well-known error pattern. We often find this error with the V591 diagnostic in various open-source projects. You can see the examples here.

Well, if everything's clear and errors are found, why did I write this article? Here comes the fun part!

The problem is that developers often interpret undefined behavior a bit different than it really is. Undefined behavior with the forgotten return statement is often interpreted as this: the function returns a random value. Moreover, the developer's previous experience may confirm this.

Wrong. Undefined behavior means we cannot predict what's going to happen. Code that worked correctly may suddenly start working in a different way.

To demonstrate this, I'll show you a slightly edited discussion (RU) from the RSDN website.

A funny crash

Linux, libc-2.33, GCC 11.1.0, optimization -O2, the following code fragment crashes with SIGSEGV:

#include <string>
#include <iostream>

bool foobar(const std::string &s)
    std::string sx = s;
    std::cout << sx << std::endl;

int main(int argc, char **argv)
    return 0;

/home/user/test$ g++ -O2 -std=c++11 ./test.cpp -o ./test && ./test

./test.cpp: In function 'bool foobar(const string&)':

./test.cpp:8:1: warning: no return statement in function returning non-void [-Wreturn-type]

8 | }

| ^


Segmentation fault (core dumped)

If we change bool foobar to void foobar or add return false, code doesn't crash.

It also doesn't crash if we use GCC 7.5.0.

By the way, std::string, as it turned out, doesn't affect the situation. The analog of this code on C, compiled by g++, also crashes.

#include <stdio.h>

bool foobar(const char *s)
    printf("foobar(%s)\n", s);

int main(int argc, char **argv)
    return 0;

/home/user/test$ g++ -O2 ./test.c -o ./test && ./test

./test.c: In function 'int foobar(const char*)':

./test.c:6:1: warning: no return statement in function returning non-void [-Wreturn-type]

6 | }

| ^


Segmentation fault (core dumped)

If we write this: gcc -O2 ./test.c -o ./test && ./test, everything's fine.

The compiler just won't generate instruction for returning from the function (ret)!

0000000000001150 <_Z6foobarPKc>:
 1150:  48 89 fe              mov   rsi,rdi
 1153:  48 83 ec 08           sub   rsp,0x8
 1157:  48 8d 3d a6 0e 00 00  lea   rdi,[rip+0xea6]  # 2004 <_IO_stdin_used+0x4>
 115e:  31 c0                 xor   eax,eax
 1160:  e8 cb fe ff ff        call  1030 <printf@plt>
 1165:  66 2e 0f 1f 84 00 00 00 00 00   cs nop WORD PTR [rax+rax*1+0x0]
 116f:  90                    nop

0000000000001170 <__libc_csu_init>:
 1170:  f3 0f 1e fa           endbr64 
 1174:  41 57                 push  r15

Thanks to the ononim user from the RSDN website for a very entertaining example.

A very unusual example of undefined behavior.

What conclusions can be drawn from this? In my opinion there are two of them:

  • Don't try to guess where undefined behavior will lead you to. If you think that you, for example, know what the signed integer overflow will lead to, then this is self-deception. There may be a very unexpected result.
  • Code that causes undefined behavior may stop working at any time. Use compiler warnings and static code analysis tools (for example, PVS-Studio) to find and fix such dangerous code fragments.

Additional links:

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus