arXiv:2606.12064v1 [cs.SE] 10 Jun 2026
Undefined Behavior in C and C++: An Experiment With Desktop Use Cases Jukka Ruohonen
Krzysztof Sierszecki
University of Southern Denmark Email: [email protected]
University of Southern Denmark Email: [email protected]
Abstract—Undefined behavior is idiomatic to C and C++ programming; such behavior is a use of an erroneous program construct for which the languages impose no requirements, such as integer overflows. The paper presents an empirical experiment seeking to probe the extent of undefined behavior executing underneath typical desktop use of a Linux distribution. The analysis is based on an undefined behavior sanitizer implemented in a compiler. According to the results, undefined behavior is common. By completing 59 simple experimental tasks, nearly 11 thousand unique undefined behavior warnings were generated by 32 unique programs and libraries written in C or C++. Of these warnings, most were associated with the Mesa graphics library and generated by interacting with graphical user interfaces. Merely logging into the GNOME desktop environment generated over 500 unique warnings. Of all warnings, the clear majority was about virtual table pointers. The associated stack traces were also lengthy in general. With these and other results, the paper contributes to the empirical literature on C and C++. Index Terms—Linux, code sanitizers, UBSan, quasi-experiment
I. I NTRODUCTION Code sanitizers are auxiliary tools used by compilers for inserting instrumentation code at runtime to detect bugs and other suspicious behavior. Especially when used with other software testing techniques, including fuzzing, sanitizers have been used to find countless vulnerabilities and conventional, non-security bugs, including in operating system kernels [1], [2]. Also the undefined behavior sanitizer (UBSan) has received appraisals from developers. Some teams “have found it to be invaluable to improve security” [3]. Although false positives are a problem with all sanitizers, including “harmless undefined behavior instances” in the present context, even simple exploratory exercises with UBSan have caught many real bugs [4]. Thus, UBSan has filled a demand because traditionally—and possibly still so—undefined behavior was difficult to identify and diagnose, causing a risk of developers incorrectly brushing it off as “GCC bugs” [5, p. 1]. With these motivating introductory points in mind, the paper presents an empirical experiment of undefined behavior in typical desktop use of open source software (OSS) written in C and C++. The motivating question is: how much undefined behavior is a hypothetical user using a desktop Linux witnessing? As soon discussed in Section II, the research questions specified in Section III can be further motivated by many relevant points. Among these is a tangential question about how much potential security and other risks is she taking?
The experiment is conducted with the UBSan implementation of the GNU Compiler Collection (GCC). It resembles closely a similar UBSan implementation in the the Clang frontend for the LLVM compiler back-end [6]. In fact, even the GCC’s documentation [7] references Clang’s documentation on its sanitizer for undefined behavior. The focus on GCC alone can be further justified on the grounds that the experiment took relatively long time to conduct and results are exploratory, shedding light on the extent of undefined behavior executing underneath conventional desktop use of Linux. After the two already mentioned sections on the background, including related work, and the research questions, the experimental setup is elaborated in Section IV. Results are presented in Section V. Sections VI, VII, and VIII present the conclusion reached, a few limitations, and closing remarks. II. BACKGROUND AND R ELATED W ORK The old C99 standard defines undefined behavior as a “behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements” [8, p. 4]. Thus, undefined behavior is essentially something that has not been specified as a requirement. The examples are many, ranging from programming mistakes to nonportable operations. Responses to undefined behavior range “from ignoring the situation completely with unpredictable results” to “terminating a translation or execution” [8, p. 4]. From a perspective of developers, undefined behavior is thus something that should be avoided. Some, but not all, undefined behavior is known to be associated with security vulnerabilities [9]. Reliability and portability are further reasons for seeking to eliminate undefined behavior. At the same time, compilers are exploiting undefined behavior for aggressive optimizations, which may yield surprising results for developers [5], [10]. Undefined behavior is thus both a bug and a feature [11, p. 345]. Yet, even in case a given undefined behavior being optimized was not risky as such, it may be that the optimizations themselves “lead to unpredictable defects and vulnerabilities”, and any undefined behavior “not yet addressed may become the new major candidate for attackers to leverage for nefarious purposes” [9, p. 9]. Compiler optimizations have indeed been observed to sometimes cause security bugs because compilers generally assume that a source code is free of undefined behavior [12]. The point is strengthened by results indicating that the performance
gains from optimizations involving undefined behavior are only small [13]. Regardless, these points signify a general trade-off involving not only developers and compilers but also standardization of the C and C++ programming languages. Even when a language standard imposes explicit requirements and thus rules out undefined behavior, the so-called Hyrum’s law should be recalled—it states that when the amount of users grows over time, “it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody” [14, p. 8]. Furthermore, standards evolve too; introducing a new feature for C or C++ may open a door for new undefined behavior. In addition to these related works about undefined behavior in C and C++, there exists a lot of previous research on code sanitizers. Sanitizers specific to addresses, memory, and threads have all been actively examined [15], [1], [16]. Also UBSan has been examined previously [12], [17]. In fact, there is research demonstrating bugs in also in many code sanitizers themselves, including but not limited to UBSan [18]. Finally, it is worth mentioning existing and related empirical research about Linux distributions and packages distributed via them [19], [20]. However, to the best of the authors’ knowledge, no directly comparable work existing about studying undefined behavior with exploratory methods, which are about “studying objects in their natural setting and letting the findings emerge from the observations” [21, p. 12; italics added]. The emphasis on natural setting is there to stress that the empirical experiment conducted is not about testing a sample of open source software with UBSan. Instead, it is about studying undefined behavior in a natural setting of desktop Linux use. Watching a video on YouTube with a web browser is a natural way to use a desktop for numerous people. This simple example also demonstrates methodological novelty; watching a video on YouTube with a web browser executes a lot of code that is external to the web browser in itself. III. R ESEARCH Q UESTIONS The following research questions (RQs) are examined: RQ1 : How much undefined behavior is detected with the GCC’s UBSan implementation when completing typical tasks on a desktop Linux distribution? RQ2 : Are some particular programs and libraries (PaLs) often used on a Linux desktop particularly prone to generate undefined behavior warnings? RQ3 : Is undefined behavior in C and C++ more prevalent with some specific task categories, such as system administration, web browsing, or office work? RQ4 : How long are the stack traces of undefined behavior warnings generated by UBSan on average? RQ5 : What kind of undefined behavior is detected by the GCC’s UBSan given the experimental tasks? On the one hand, the “how much” wording used for RQ1 further underlines the exploratory nature of the experiment. In other words: prior to conducting the experiment and writing
the paper, neither of the authors could deduce about a sensible hypothesis regarding the potential amount of undefined behavior—even after reading numerous papers on the topic, some of which are referenced in Section II. On the other hand, the answer to RQ1 signifies also the value of exploratory research; now there is a sensible hypothesis for further work. IV. E XPERIMENTAL S ETUP A. Environment The data collection in May 2026 process followed closely the one used in recent research [20]. After having installed the Gentoo’s minimal installation medium for the x86_64 instruction set architecture [22] to a Qemu virtual machine, a desktop-specific userland [23], or “stage” in the Gentoo’s parlance, was installed and a profile was subsequently specified to be GNOME-specific.1 During the installation process, all packages recommended for a desktop system were installed according to a manual provided [24]. The final step was the installation of additional packages, including the GNOME desktop environment itself. Regarding the other packages, these can be deduced from Table I in Subsection IV-B. Unlike in related research [20], Gentoo’s default compiling options were used. These include optimizations, which have also been recommended for UBSan [3]. Given guidelines [25] and the Gentoo’s make.conf configuration file for building packages, the following options were thus used for compiling: COMMON_FLAGS="-march=native -O2 -pipe" CFLAGS="${CFLAGS} -fsanitize=undefined" CXXFLAGS="${CXXFLAGS} -fsanitize=undefined" LDFLAGS="${LDFLAGS} -fsanitize=undefined" USE="${USE} custom-cflags network-manager \ -clang -luajittex"
With these options, all packages in the installation were recompiled with the GCC version 15.2.1 released in 2025.2 Another configuration used was about UBSan’s runtime behavior. Similarly to panic-causing assertions in kernels [28], and to ease debugging, some have preferred UBSan’s option to abort the execution of a process upon it triggering undefined behavior [29]. As the intention of the experiment is empirical, such options were not used. Instead, the following two configuration options were embedded to a global environmental variable: UBSAN_OPTIONS="log_path=$HOME/ubsan/ubsan: \ print_stacktrace=1"
By implication, the GCC’s UBSan implementation logs at runtime each detected undefined behavior into a file $HOME/ubsan/ubsan.[pid], where [pid] denotes the process identifier number of the corresponding process having caused the given undefined behavior. These files contain also 1 default/linux/amd64/23.0/desktop/gnome
(stable)
2 This GCC version uses the C23 and C++17 language versions for C and
C++ by default [26], [27], although it may be that some packages specify their own flags also in this regard. Furthermore, the sanitizer option had to be omitted for the app-arch/xz-util, app-text/texlive-core, dev-qt/qtbase, dev-qt/qtquick3d, kde-frameworks/kio, net-libs/webkit-gtk, and x11-libs/gtk+ packages because these failed to build with it.
stack traces associated with the specific binaries having caused undefined behavior logging. After parsing and quantification, the logs constitute the empirical materials for the experiment.
TABLE I E XPERIMENTAL TASKS Tij
Description
The experiment was conducted by completing the simple tasks from Ts1 to Tc11 enumerated in Table I. After completing a task, the log files outputted by UBSan, if any, were moved to a specific directory used for parsing in order to avoid mistakes. For the web browsing tasks, all caches and configuration files were deleted between the tasks with the Epiphany browser. The experiment can be classified as a technology-oriented quasi-experiment; the objects are all software and no randomization was used for the tasks experimenting with the objects [21, pp. 73–75].3 The experiment also resembles blackbox manual testing, the flexibility of which has been perceived as an important benefit among practitioners whose experience and time constraints have often guided test case selection [31]. The point about time constraints translates into a feasibility constraint in the present context; it is not feasible to test a whole operating system running a desktop environment. Because there is no directly comparable related work, nor is it possible to rely on prior knowledge—a tactic often used for selecting and prioritizing manual test cases [31], [32]. Therefore, the tasks were aligned toward the wording in the introduction about “conventional desktop use”. Watching YouTube videos is a conventional desktop use for countless of people, whereas Matplotlib, Python, R, and LATEX are used by many scientists daily. The tasks were also designed with a focus on large PaLs, which, by hypothesis, should be more prone to undefined behavior due to their large code bases. It can also be mentioned that all tasks were specified prior to having the experimental Gentoo installation ready. Therefore, the experiment does not resemble exploratory testing; cf. [33]. Finally, regarding the notion of black-box testing, it can be remarked that the authors have knowledge about C, C++, and OSS, including its development, but no actual source code was examined before, during, or after the experimental tasks.
Ts1 Ts2 Ts3 Ts4 Ts5 Ts6 Ts7 Ts8 Ts9 Ts10 Ts11 Ts12 Ts13 Ts14
System administration: Boot the system and login to a terminal as root Boot the system and login to GNOME as a normal user Execute htop Execute joe $HOME/.bashrc Execute nano $HOME/.bashrc Execute emerge www-client/lynx Execute ssh-keygen -t rsa -b 4096 Execute ssh-keygen -t ecdsa -b 521 Execute useradd foo && userdel foo Execute tar cvf archive.tar /usr/share/info Capture live traffic with Wireshark for fifteen seconds Execute openssl req -x509 -newkey rsa:4096 Execute tcpdump -c 5 & ping google.com -c 5 Open the GNOME’s graphical printer configuration application
Td1 Td2 Td3 Td4 Td5 Td6 Td7 Td8 Td9 Td10 Td11 Td12 Td13 Td14 Td15 Td16 Td17 Td18 Td19 Td20
Desktop and multimedia: Open and close the classical xterm terminal emulator Open and close the GNOME’s default terminal (Console) Open the Cheese application for web cameras Open the Chess game shipped in GNOME Play a game of Five or More shipped in GNOME Play a game of Five-in-a-row shipped in GNOME Open the weather widget application for GNOME Open the GNOME’s GNote note taking application Open an image with the Eye of GNOME image viewer Open and close the GNOME’s application for contacts Open Rhythmbox and listen a minute of Radio Paradise Convert a PNG file with ImageMagick to the GIF format Open the graphical system monitor application for GNOME Use MPlayer to play a video encoded in the H.264 format Open the clock application for GNOME start a stopwatch Write “hello world” with the text editor for GNOME Calculate 2 + 2 with the calculator application for GNOME Visit fifteen directories with the GNOME’s Files application Change the wallpaper with the GNOME’s settings application Open the graphical disk usage analyzer application for GNOME
Tw1 Tw2 Tw3 Tw4 Tw5
Web browsing: Execute curl http://example.com Execute wget http://example.com Open Lynx and visit https://ieee.org Open Epiphany and visit https://ieee.org Open Epiphany and watch a random video on YouTube
C. Parsing and Methods
To1 To2 To3 To4 To5 To6 To7 To8 To9
Office work: Open this paper with Evince Open this paper with Okular Open this paper with MuPDF Open the GnuCash accounting application Open AbiWord and write “undefined behavior” Open Gnumeric and write “123” to the cell A1 Open the Mutt email client and draft an email Open the Evolution email client and draft an email Write “new event” to 12 May 2026 in the GNOME’s calendar
Tc1 Tc2 Tc3 Tc4 Tc5 Tc6 Tc7 Tc8 Tc9 Tc10 Tc11
Scientific work: Run git init . Open the GTKWave application Generate a simple plot with gnuplot Generate a simple plot with Matplotlib Calculate a matrix multiplication with Octave Compile this paper with pdflatex Transform the PDF of this paper with pdf2ps Execute pdfunite 1.pdf 2.pdf out.pdf Open the LATEX source of this paper with XEmacs Open the LATEX source of this paper with Texmaker Open R and run a command plot(rnorm(1234))
B. Experimental Tasks
The first three research questions, RQ1 , RQ2 , and RQ3 , require only counting the amount of unique undefined behavior warnings generated by UBSan. Uniqueness is ensured because the GCC’s UBSan implementation reports each warning in a PaL with references to a specific source code file and a line number in it. Ensuring uniqueness is also important because redundancy is a known problem with many sanitizers, including UBSan; same checks are often repeatedly checked [17]. Such redundant checks are not included in the results reported—each undefined behavior warning observed is specific to a given C or C++ source code file and line in it. 3 The authors are well-aware of the regrettable misuse of the term experiment in software engineering research [30]. Therefore, to further clarify, the experiment involves manipulation because the tasks directly influence the results; hence, the technology-oriented quasi-experiment cannot be said to be an observational study. There is also some limited comparison control.
[...]
12
Mean Median
10 Frequency
Regarding RQ2 , the counting is done by recording the immediately triggering PaLs based on the stack traces. Given parsing of lines containing #0, the following stripped snippet would thus yield two unique warnings for the Gentoo’s app-editors/joe package, which is identified as joe:
8
libgs.so.10, libabiword-3.0.so, libmupdf.so.1.26.3
6 4
libgallium-25.3.6.so
2
cclass.c:1032:16: runtime error: left shift \ of negative value -32 #0 [...] (/usr/bin/joe+0xc713) [...] #1 [...] (/usr/bin/joe+0x1fb1c3) [...] #2 [...] (/usr/bin/joe+0xcdb0) [...] #3 [...] (/usr/lib64/libc.so.6+0x273ea) [...] #4 [...] (/usr/lib64/libc.so.6+0x2749a) [...] #5 [...] (/usr/bin/joe+0x115e4) [...] hash.c:22:10: runtime error: left shift [...] \ cannot be represented in type ’long int’ #0 [...] (/usr/bin/joe+0x88be) [...] #1 [...] (/usr/bin/joe+0x777d2) [...] [...]
Regarding RQ3 and with a reference to the earlier snippet in Subsection IV-A about UBSAN_OPTIONS, the unique warnings in all log files generated by UBSan are counted for each task. As for RQ4 , the above stripped snippet suffices to exemplify the parsing; the length of the first unique warning generated by executing the joe editor is taken to be five. TABLE II C ATEGORIZATION OF WARNINGS
0 0
2
4
6
8
10
Undefined warnings generated (logarithm)
Fig. 1. Undefined Warnings Generated by PaLs
Virtual pointers (88.26%) Shift operators (8.57%) NULL pointers (2.08%) Misaligned accesses (0.82%) Buffer overflows (0.14%) Integer overflows (0.05%) Variable length arrays (0.05%) Type mismatches (0.03%) 0
20
40
60
80
100
Share of all unique warnings (%)
Fig. 2. Undefined Warning Categories Category Buffer overflows
Strings • “with insufficient space for an object of type”
Integer overflows
• “signed integer overflow”
Shift operators
• “shift exponent” • “left shift of ”
Misaligned accesses
• “store to misaligned address” • “load of misaligned address” • “member access within misaligned address”
NULL pointers
• “null pointer passed as argument” • “member access within null pointer of type”
Type mismatches
• “does not point to an object of type”
Variable length arrays
• “variable length array bound”
Virtual pointers
• “object has invalid vptr”
Then, with respect to RQ5 , the warnings are categorized into eight groups shown in Table II. Most of the categories have been discussed in the literature [5]. If a given string shown in the second column of the table appears anywhere in a warning, the warning is categorized into the corresponding category. V. R ESULTS Undefined behavior is common. Out of the 59 experimental tasks conducted, as many as 36 generated at least one warning. In other words, UBSan outputted one or more warnings for about 61% of the simple experimental tasks in Table I. In total, the experimental tasks generated 10, 914 unique undefined behavior warnings. Yet, as can be deduced from
Fig. 1, these warnings are extremely unequally distributed across the 32 unique PaLs that generated undefined behavior warnings from the 59 experimental tasks conducted. In fact, libgallium-25.3.6.so, which is part of the low-level Mesa graphics library, accounted for about 98% of all unique warnings. The Mesa’s 10, 723 unique warnings are associated with 20 experimental tasks. Even without saying anything about true and false positives, these numbers underline that Mesa is frequently executed on a desktop Linux. At the other end of the empirical distribution in Fig. 1, about 38% of the unique PaLs identified generated just one unique warning. Regarding the types of warnings outputted by UBSan, the overwhelming majority are about virtual pointer tables used by compilers for C++. As seen from Fig. 2, also bitwise shift operators were relatively common. Two of the tasks, Td14 and Tc7 , generated warnings hinting about potential buffer overflows. The warnings associated with these two tasks were further associated with libavformat.so.60 and libgs.so.10, a multimedia library and a library for Ghostscript. Otherwise, a notable takeaway from Fig. 2 is that signed integer overflows were only seldom detected by UBSan. The distribution of the warnings is unequal also across the experimental tasks. Although the tasks are not strictly comparable in statistical terms, most (about 66%) of the unique
Mean Median
800
Task category
Undefined warnings generated
1000
600
System administration Desktop and multimedia Web browsing Office work Scientific work
400 0 200
2000
4000
6000
8000
Undefined warnings generated
0 d19
d2
d10 s11
d7
w5
s2
o9
w4
d16 d17 d20
d4
d8
d13
d3
s14
o3
o5
c7
d14
o4
o8
d11
o1
c4
s4
c11
c3
c5
o2
o6
o7
s3
s6
w3
Task (subscript)
Fig. 3. Undefined Warnings Generated by Tasks (only tasks having generated at least one warning are shown)
libgallium-25.3.6.so libvulkan_intel_hasvk.so ft2font.cpython-313-x86_64-linux-gnu.so libmutter-clutter-16.so.0 libX11.so.6 libabiword-3.0.so _multiarray_umath.cpython-313-x86_64-linux-gnu.so libasound.so.2 _backend_agg.cpython-313-x86_64-linux-gnu.so libXt.so.6 libgs.so.10 libtinfow.so.6 okular
Task (subscript)
libguile-3.0.so.1
PaL
libgvfsdbus.so libgsttag-1.0.so.0 libgstogg.so libglib-2.0.so.0 libmupdf.so.1.26.3 gvfsd-metadata libtinfo.so.6 libmutter-16.so.0 libXfont2.so.2 swrast_dri.so xkbcomp goffice.so joe
Maximum
libXau.so.6 libgsttypefindfunctions.so
Mean
libavformat.so.60
Mean across means
gnuplot mupdf-gl
0
50
100 150 200
Stack trace length
d7 s2 o8 c4 d3 s11 s14 d2 d10 d19 o9 o5 d8 d16 d20 w4 w5 d13 d17 d4 c11 s6 c7 c5 o2 o4 o1 o3 d11 c3 w3 s3 o7 o6 d14 s4
Maximum Mean Mean across means
0
50
100
150
200
Stack trace length
Fig. 4. Trace Lengths Across PaLs Having Generated One or More Warnings
Fig. 5. Trace Lengths Across Tasks Having Generated One or More Warnings
undefined behavior warnings were associated with the desktop and multimedia tasks. As seen from the smaller inner plot in Fig. 3, also the system administration tasks generated a lot of warnings. However, as can be deduced from the outer plot in the figure, most of the warnings generated by the system administration tasks were related to graphical user interfaces (in particular, Ts11 , Ts2 , and Ts14 ). Merely logging in to the
GNOME desktop environment and trying to configure a printer generated almost one thousand unique warnings. Also the many warnings generated by UBSan when using the graphical user interface of Wireshark to record network traffic are worth noting due to the program’s history with vulnerabilities.4 The 4 https://www.cvedetails.com/version-list/0/8292/1/
larger outer plot in Fig. 3 also reiterate the earlier point about Mesa. In particular, the desktop use cases Td2 , Td10 , and Td19 all generated a lot of unique undefined behavior warnings associated with the noted libgallium-25.3.6.so library. Mesa stands out also in terms of the stack trace lengths. When the maximum trace lengths are considered, Mesa’s two libraries take the topmost places in the ranking shown in Fig. 4. If mean lengths are considered, the Mesa’s Gallium library and libvulkan_intel_hasvk.so do not rank as high, indicating a large variance in the traces and their lengths generated by these two libraries. In contrast, the variance is small for the traces generated by ft2font.cpython-313-x86_64-linux-gnu.so, libmutterclutter-16.so.0, and libX11.so.6, among a few other PaLs. In other words: for the three noted PaLs, the stack traces have been consistently lengthy. When the trace lengths are considered in terms of the experimental tasks, it is interesting that a simple weather widget (as per the Td7 task) generated the lengthiest traces. When maximums are considered, the second place is taken by Ts2 , the task of logging into the GNOME desktop environment. When compared to the weather widget, this observations seems more logical because a lot of code is executed once a user logs into GNOME. Although To8 , the task involving the Evolution email client, takes the third place in Fig. 5, the trace lengths do not seem to consistently vary across program sizes. For instance, the tasks associated with Matplotlib and the Cheese web camera application (Tc4 and Td3 , respectively) also generated a few particularly lengthy stack traces. All in all, these observations can be used for supporting a tentative argument that undefined behavior may not correlate as strongly with software size as the volume of real, verified bugs is known to correlate; cf. [34], among others. A further point is that even simple graphical user interfaces and small programs in general can generate a lot of undefined behavior that is attributable to low-level libraries written in C and C++. Therefore, it can also be argued that these are the areas to which effort should be devoted for reducing the volume of undefined behavior executing underneath typical desktop use of Linux. Debugging is required also for verifying whether the warnings observed and generated by the GCC’s UBSan are actual true positives. That said, the point is easy to raise but likely difficult in practice because undefined behavior is generally difficult to learn, debug, and avoid even by experienced programmers [12]. As with the GCC’s some other options [20], another argument can therefore be raised that improving the warnings outputted by UBSan might pay off. VI. C ONCLUSION The answers to the five research questions can be summarized as follows: undefined behavior is very common with common desktop use cases (RQ1 ), but some programs and libraries—particularly those associated with Mesa—are more prone to generate undefined behavior warnings (RQ2 ); undefined behavior is also more common with desktop and multimedia tasks involving graphical user interfaces (RQ3 ); the
stack traces associated with undefined behavior warnings are lengthy on average, although also these vary across programs and libraries (RQ4 ); and virtual table pointers and—to a much lesser extent—shift operators, NULL pointers, and misaligned accesses are behind most of the warnings observed (RQ5 ). VII. L IMITATIONS The following four limitations should be acknowledged: 1) Selection bias is a typical issue in software engineering quasi-experiments [35]. Even though an attempt was made to slightly control it by allowing both authors to suggest tasks prior to conducting the experiment, it must be acknowledged that the tasks may not represent the tasks typical to desktop Linux use among people using desktop Linux. To address the limitation, a survey could be used in further work about typical desktop use cases. Even then, it should also be remarked that some packages failed to compile with UBSan—among them, notably, Firefox and LibreOffice. These had to be thus omitted. 2) UBSan is known to miss a lot of undefined behavior [12]. Thus, particularly the answer to RQ1 is only tentative. In reverse: false positives are presumably also present. 3) Many of the technical limitations elaborated in closely related existing work [20] apply also the current work. For instance, some packages are known to force their own compiler flags, ignoring those specified in a distribution [19]. Such technical details may affect all of the RQs, although the effect can be argued to be only small. The bias was also mitigate by using the USE flag custom-cflags as a global option for all packages. 4) Many undefined behaviors are specific to hardware; an undefined behavior in some instruction set architecture may not be undefined behavior in some other architecture [5], [10]. Thus, conducting the experiment on a x86_64-based Qemu virtual machine must be acknowledged as a limitation. It could even be that some of the undefined behaviors detected are not about the software experimented with it but about Qemu’s (in)ability to emulate; cf. [36]. Some bugs are also known to only occur on real hardware [37]. That said, it is difficult to say anything specific about the severity of this limitation except that it should be relatively minor because Qemu is supposedly particularly good at emulating x86_64. VIII. C LOSING R EMARKS The results presented reiterate an argument from 2017 in which the authors stated “the obvious – that, despite the many excellent advances in tooling over the last few years”, problems with undefined behavior “are far from solved” [38]. Then, when having to live with undefined behavior, a recommendation to “be very careful, use good tools, and hope for the best” [39] seems sensible. Even though the tooling has improved thanks to UBSan and other sanitizers, using software usually rests on an implicit or explicit assumption of others
having been careful. Therefore, on the one hand, trusting others and hoping for the best is what most desktop users can really only count on. For developers, on the other hand, debugging and fixing undefined behavior may be challenging [12], and, therefore, another recommendation [10] to turn on various related compiler options seems still sensible. When developing new software with the C and C++ programming languages, it is a good idea to turn also UBSan on by default. R EFERENCES [1] J. Ruohonen and K. Rindell, “Empirical Notes on the Interaction Between Continuous Kernel Fuzzing and Development,” in Proceedings of the IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW 2019). Berlin: IEEE, 2019, pp. 276–281. [2] D. Song, J. Lettner, P. Rajasekaran, Y. Na, S. Volckaert, P. Larsen, and M. Fran, “SoK: Sanitizing for Security,” in Proceedings of the IEEE Symposium on Security and Privacy (S&P). San Francisco: IEEE, 2019, pp. 1275–1295. [3] E. Zannoni, “Improving Application Security with UndefinedBehaviorSanitizer (UBSan) and GCC,” 2021, Oracle Linux Blog, available online in 10 May 2026: https://blogs.oracle.com/linux/improving-applicationsecurity-with-undefinedbehaviorsanitizer-ubsan-and-gcc. [4] K. Packard, “Fun With -fsanitize=undefined and Picolibc,” 2025, Available online in 10 April 2026: https://keithp.com/blogs/sanitizer-fun/. [5] X. Wang, H. Chen, A. Cheung, Z. Jia, N. Zeldovich, and M. F. Kaashoek, “Undefined Behavior: What Happened to my Code?” in Proceedings of the Asia-Pacific Workshop on Systems (APSYS 2012). Seoul: ACM, 2021, pp. 1–7. [6] The Clang Team, “UndefinedBehaviorSanitizer,” 2026, Available online in 10 April 2026: https://clang.llvm.org/docs/ UndefinedBehaviorSanitizer.html. [7] Free Software Foundation, Inc., “3.13 Program Instrumentation Options,” 2026, Available online in 10 April 2026: https://gcc.gnu.org/ onlinedocs/gcc/Instrumentation-Options.html. [8] WG14/N1256, “Committee Draft – Septermber 7, 2007 ISO/IEC 9899:TC3,” 2007, International standardization working group for the programming language C. Available online in 11 April 2026: https: //www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf. [9] T. Doumler and J. Berne, “A Framework for Systematically Addressing Undefined Behaviour in the C++ Standard,” 2025, JTC1/SC22/WG21 – The C++ Standards Committee – ISOCPP, available online in May 2026: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/ p3100r5.pdf. [10] X. Wang, N. Zeldovich, M. F. Kaashoek, and A. Solar-Lezama, “A Differential Approach to Undefined Behavior Detection,” Communications of the ACM, vol. 59, no. 3, pp. 99–106, 2016. [11] C. Hathhorn, C. Ellison, and G. Ros, “Defining the Undefinedness of C,” in Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2015). Portland: ACM, 2015, pp. 336–345. [12] J. Xu, K. Lu, Z. Du, Z. Ding, L. Li, Q. Wu, M. Payer, and B. Mao, “Silent Bugs Matter: A Study of Compiler-Introduced Security Bugs,” in Proceedings of the 32nd USENIX Security Symposium (USENIX 2023). Anaheim: USENIX, 2023, pp. 3655–3672. [13] L. Popescu and N. P. Lopes, “Exploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the Performance Impact,” Proceedings of the ACM on Programming Languages, vol. 9, no. PLDI, pp. 348–371, 2025. [14] T. Winters, T. Manshreck, and H. Wright, Software Engineering at Google: Lessons Learned From Programming Over Time. Sebastopol: O’Reilly, 2020. [15] Y. Nong and H. Cai, “A Preliminary Study on Open-Source Memory Vulnerability Detectors,” in Proceedings of the IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER 2020), London, 2020, pp. 557–561. [16] N. I. Výukovaa, V. A. Galatenkoa, and S. V. Samborskii, “Dynamic Program Analysis Tools in GCC and CLANG Compilers,” Programming and Computer Software, vol. 46, pp. 81–296, 2020. [17] J. Zhang, S. Wang, M. Rigger, P. He, and Z. Su, “SanRazoR: Reducing Redundant Sanitizer Checks in C/C++ Programs,” in Proceedings of the 15th USENIX Symposium on Operating Systems Design and Implementation. Online: USENIX, 2021, pp. 479–494.
[18] S. Li and Z. Su, “UBFuzz: Finding Bugs in Sanitizer Implementations,” pp. 435–449, 2024. [19] E. Rocca, “Packages Not Using The Default Build Flags: A Taxonomy,” in Proceedings of the 26th Debian Conference (DebConf 2025), Brest, 2025, pp. 1–5, available online in 11 April 2026: https://hal.science/hal05334704/document. [20] J. Ruohonen, M. Saddiqa, and K. Sierszecki, “A Static Analysis of Popular C Packages in Linux,” in Proceedings of the 22nd Annual International Conference on Privacy, Security, and Trust (PST 2025). Fredericton: IEEE, 2025, pp. 1–10. [21] C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, and A. Wesslén, Experimentation in Software Engineering, 2nd ed. Heidelberg: Springer, 2024. [22] Gentoo, “Minimal Installation CD,” 2026, available online in 10 April 2026: https://distfiles.gentoo.org/releases/amd64/autobuilds/ 20260408T183104Z/install-amd64-minimal-20260408T183104Z.iso. [23] ——, “Default Stage Archives: Stage Desktop Profile & OpenRC,” 2026, available online in 10 April 2026: https://distfiles.gentoo.org/ releases/amd64/autobuilds/20260410T130145Z/stage3-amd64-desktopopenrc-20260410T130145Z.tar.xz. [24] ——, “Gentoo AMD64 Handbook,” 2026, available online in 10 April 2026: https://wiki.gentoo.org/wiki/Handbook:AMD64. [25] ——, “UndefinedBehaviorSanitizer,” 2026, available online in 10 April 2026: https://wiki.gentoo.org/wiki/UndefinedBehaviorSanitizer. [26] Free Software Foundation, Inc., “C Standards Support in GCC,” 2026, Available online in 10 June 2026: https://gcc.gnu.org/projects/c-status. html#c23. [27] ——, “C++ Standards Support in GCC,” 2026, Available online in 10 June 2026: https://gcc.gnu.org/projects/cxx-status.html?#cxx17. [28] J. Ruohonen, “A Time Series Analysis of Assertions in the Linux Kernel,” in Proceedings of the 37th International Conference on Testing Software and Systems (ICTSS 2025). Limassol: Springer, 2026, pp. 3–15. [29] J. Kratochvil, “Memory Error Checking in C and C++: Comparing Sanitizers and Valgrind,” 2021, Red Hat Developer Blog, available online in 10 April 2026: https://developers.redhat.com/blog/2021/05/05/ memory-error-checking-in-c-and-c-comparing-sanitizers-and-valgrind. [30] C. Ayala, B. Turhan, X. Franch, and N. Juristo, “Use and Misuse of the Term “Experiment” in Mining Software Repositories Research,” IEEE Transactions on Software Engineering, vol. 48, no. 11, pp. 4229–4248, 2022. [31] R. Haas, D. Elsner, E. Juergens, A. Pretschner, and S. Apel, “How Can Manual Testing Processes Be Optimized? Developer Survey, Optimization Guidelines, and Case Studies,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2021). ACM, 2021, pp. 1281–1291. [32] H. Hemmati, Z. Fang, M. V. Mäntylä, and B. Adams, “Prioritizing Manual Test Cases in Rapid Release Environments,” Journal of Software: Testing, Verification and Reliability, vol. 27, no. 6, p. e1609, 2017. [33] J. Itkonen, M. V. Mäntyla, and C. Lassenius, “Defect Detection Efficiency: Test Case Based vs. Exploratory Testing,” in Proceedings of he First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007). Madrid: IEEE, 2007, pp. 61–70. [34] H. Zhang, “An Investigation of the Relationships Between Lines of Code and Defects,” in Proceedings of the IEEE International Conference on Software Maintenance (ICSM 2009), Edmonton, 2009, pp. 274–283. [35] V. B. Kampenes, T. Dybå, J. E. Hannay, and D. I. K. Sjøberg, “A Systematic Review of Quasi-Experiments in Software Engineering,” Information and Software Technology, vol. 51, pp. 71–82, 2009. [36] M. Jiang, T. Xu, Y. Zhou, Y. Hu, M. Zhong, L. Wu, X. Luo, and K. Ren, “Automatically Locating ARM Instructions Deviation Between Real Devices and CPU Emulators,” 2021, archived manuscript, available online in 12 April 2026: https://arxiv.org/abs/2105.14273. [37] W. Choe, R. Wang, A. Benazir, and F. X. Lin, “Proto: A Guided Journey Through Modern OS Construction,” in Proceedings of the ACM SIGOPS 31st Symposium on Operating Systems Principles (SOSP 2025). Seoul: ACM, 2025, pp. 50–66. [38] P. Cuoq and J. Regehr, “Undefined Behavior in 2017,” 2017, available online in June 2026: https://blog.regehr.org/archives/1520. [39] J. Regehr, “A Guide to Undefined Behavior in C and C++, Part 1,” 2010, available online on 12 April 2026: https://blog.regehr.org/archives/213.